[Drefvelin]

Summary

The robbery guild cooldown was only checked when a robber right-clicked a target. A pending request skipped it: two members of one guild could each send a request to the same victim before either was accepted, and both robberies would go through.

acceptRobbery now checks the cooldown again before recording it. If a guildmate's robbery was accepted while this request was pending, the request is cancelled. The victim sees "That robbery request has expired" and the robber is told why.

Cooldown audit

I checked every Thievery cooldown against main:

Type	Status
Robbery (3 days, guild-wide)	Fixed here: now also checked on accept
Pickpocket (1 hour, guild-wide)	Already correct
Container lockpick (3 days, guild-wide)	Already correct
Door lockpick (60 s after a failed attempt)	Unchanged on purpose
Paper key copy (240 minutes)	Already correct

The other two problems I looked into are already fixed on main:

• Resetting one player's cooldowns now clears both their robbery and pickpocket entries. The || short-circuit is gone.
• The guild-wide check now matches members by account UUID through Members.accountId, so it no longer calls Bukkit.getOfflinePlayer(name).

Testing

• mvn clean verify: 1075 tests pass and the coverage gate is met.
• New test: RobberyManagerTest.acceptanceRechecksTheGuildCooldownSoPendingRequestsCannotBypassIt.

🤖 Generated with Claude Code

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 99f340f2-10bd-4739-8530-14806aa11803

📥 Commits

Reviewing files that changed from the base of the PR and between 433b77f and 8978fc8.

📒 Files selected for processing: 2

• src/main/java/net/tfminecraft/thievery/robbery/RobberyManager.java
• src/test/java/net/tfminecraft/thievery/robbery/RobberyManagerTest.java

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

📝 Summary

Summary by CodeRabbit

• Bug Fixes
  • Guild robbery cooldowns are now checked when a pending request is accepted. If the cooldown is active, the request expires and both players are notified. No robbery session starts, and no new cooldown or target data is recorded for that request. This keeps the outcome consistent whether the cooldown is active when a request is made or when it is accepted.

When a victim accepts a pending robbery request, acceptRobbery checks the robber’s guild cooldown again. If the cooldown is active, it sends messages to both players, ends the session and rejects the request. A test covers this case.

Changes: Robbery acceptance cooldown

Layer / File(s)	Summary
Acceptance-time cooldown validation src/main/java/net/tfminecraft/thievery/robbery/RobberyManager.java, src/test/java/net/tfminecraft/thievery/robbery/RobberyManagerTest.java	Acceptance now rejects a request if the robber’s guild is on cooldown for the victim. The test checks the messages, request removal and absence of a session, restraint, cooldown record or target-data save.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: ryanbarlow97

Merge Risk: ⚪ Minimal · up to 8978f

The change rechecks the guild cooldown before proceeding with a robbery and rejects and cleans up the pending request when the cooldown is active. No actionable merge risk is established.

- [ ] Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}