Skip to content

fix(war): pass the war accept event its guilds in the right order - #830

Merged
darbyjack merged 1 commit into
masterfrom
fix/war-accept-event-argument-order
Oct 5, 2026
Merged

darbyjack merged 1 commit into
masterfrom
fix/war-accept-event-argument-order

Conversation

@darbyjack

Copy link
Copy Markdown
Member

Summary

GuildWarAcceptEvent takes its two guilds challenger-then-defender and passes the defender to GuildEvent as event.guild. CommandWar.accept() passed them the other way round.

 fun accept(player: Player, guild: Guild) {
   val challenge = challengeHandler.getChallenge(guild) ?: ...
   val challenger = challenge.challenger
+  // challenge.defender == guild, so guild is the defender
-  val event = GuildWarAcceptEvent(player, guild, challenger)
+  val event = GuildWarAcceptEvent(player, challenger, guild)

What a listener saw before and after:

property before after
event.challenger defender challenger
event.defender challenger defender
event.guild challenger defender

Evidence

accept() refuses unless challenge.defender == guild, so the command's guild is always the defender. Position 2 is challenger and position 3 is defender, so the old call handed each guild the other's slot.

The two sibling call sites already pass challenger first and are untouched:

CommandWar.challenge  GuildWarChallengeEvent(player, guild, targetGuild)   # guild is the challenger
CommandWar.deny       GuildWarDeclineEvent(player, challenger, guild)       # correct
CommandWar.accept     GuildWarAcceptEvent(player, guild, challenger)       # swapped

./gradlew test testJava11 passes.

Testing

No test was added. Nothing under src/test referenced GuildWarAcceptEvent and there were no war command tests to extend. Covering this would need a new pattern for driving a BaseCommand subclass: the handler reaches for Bukkit.getPluginManager(), and the code after the event fires needs ACF's currentCommandManager, which does not exist without a server. The existing suite tests handlers and domain objects directly rather than commands, so this would be new scaffolding, which is out of scope here.

Merge Danger

Door: two-way

Reverts with a single commit.

Blast Radius: plugin API consumers

GuildWarAcceptEvent's constructor signature is unchanged, so nothing breaks at compile time. Listeners reading challenger, defender or guild get the correct guild going forward. Listeners that worked around the swap will need updating.

GuildWarAcceptEvent declares its guild parameters challenger then defender and
hands the defender to GuildEvent as event.guild. The call site in CommandWar
passed them the other way round, so event.challenger held the defending guild,
event.defender held the challenging guild, and event.guild reported the
challenger as the guild that accepted.

accept() only runs for the defender, since it refuses unless
challenge.defender is the sender's guild, so the command's guild is always the
defender and swapping the two arguments is always wrong. The decline and
challenge call sites already pass challenger first.

The event's own callers were the only ones affected. Nothing in this plugin
reads these properties back.
@darbyjack
darbyjack merged commit 1489481 into master Oct 5, 2026
2 checks passed
@darbyjack
darbyjack deleted the fix/war-accept-event-argument-order branch October 5, 2026 17:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant