Fix status_changed event not firing on board drag

Matt Nohrrequested to merge
duo/fix/628326-board-drag-status-changed-event into master

What does this MR do and why?

Dragging a work item card between status lists on an issue board changed the item's status but did not publish the WorkItems::StatusChangedEvent cloud event, so Duo Agent Platform flow triggers registered for the work_item event with the status_changed action never fired for board drags.

Root cause: WorkItems::Callbacks::Status#after_update_commit infers "did the status change?" from previous_changes on work_item.current_status. Board drags resolve the issuable through IssuesFinder, so the callback holds a plain Issue, and WorkItems::Widgets::Statuses::UpdateService#ensure_work_item writes the status to a freshly loaded WorkItem instead. sync_original_association then called @original.association(:current_status).reset, so when after_update_commit re-read work_item.current_status it got a freshly loaded record with empty previous_changes and returned early without publishing.

Fix: hand the caller the record that was just written instead of forcing a reload:

@original.association(:current_status).target = work_item.current_status

The Issue still reads the new value — preserving the webhook payload fix from 360092d4 — and previous_changes stays intact so after_update_commit publishes the event.

Tests:

  • New #after_update_commit example in ee/spec/services/work_items/callbacks/status_spec.rb that runs the callback with a plain Issue (the board-drag path) and asserts the event is published. This path was previously untested.
  • New example in ee/spec/services/work_items/widgets/statuses/update_service_spec.rb asserting an Issue caller receives the written record with previous_changes preserved.
  • The existing webhook-related specs from 360092d4 (ee/spec/services/ee/issues/close_service_spec.rb, reopen_service_spec.rb, update_service_spec.rb, and the Issue-caller example in update_service_spec.rb) are unchanged in behavior and continue to cover the webhook payload path.

Note: the specs could not be executed in the authoring environment (no PostgreSQL/Redis services available); they are expected to run in CI.

References

Screenshots or screen recordings

Backend-only change; no user-visible UI changes.

How to set up and validate locally

  1. On a project with the work_item_status licensed feature enabled, create an issue board with status lists.
  2. Create an Ai::FlowTrigger for event type work_item with the status_changed action.
  3. Drag a card from one status list to another.
  4. Before: the status updates but no WorkItems::StatusChangedEvent is published and the flow trigger does not run. After: the event is published and the trigger runs.

Faster, in a Rails console:

# Board drag path: a plain Issue. Publishes WorkItems::StatusChangedEvent after this fix.
Issues::UpdateService.new(container: project, current_user: user, params: { status: some_status })
  .execute(Issue.find(id))

Run the specs:

bundle exec rspec \
  ee/spec/services/work_items/callbacks/status_spec.rb \
  ee/spec/services/work_items/widgets/statuses/update_service_spec.rb \
  ee/spec/services/ee/issues/close_service_spec.rb \
  ee/spec/services/ee/issues/reopen_service_spec.rb \
  ee/spec/services/ee/issues/update_service_spec.rb

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports