### Summary Dragging a work item card between status lists on an issue board changes the item's status, but does not publish the `WorkItems::StatusChangedEvent` cloud event. As a result, Duo Agent Platform flow triggers registered for the `work_item` event with the `status_changed` action never fire for board drags, even though they fire correctly when the status is changed directly on the work item. Reported by a user building a Factory proof-of-concept who extended the work item status trigger with a filter so they could run a different trigger per stage. ### Steps to reproduce UI: 1. On a project with the `work_item_status` licensed feature enabled, create an issue board with status lists. 1. Create an `Ai::FlowTrigger` for event type `work_item` with the `status_changed` action. 1. Drag a card from one status list to another. 1. Observe that the card's status updates in the board, but the flow trigger does not run. 1. For comparison, change the same work item's status directly from the work item view. The trigger runs. Faster, in a console or spec: ```ruby # Board drag path: a plain Issue. Does NOT publish WorkItems::StatusChangedEvent. Issues::UpdateService.new(container: project, current_user: user, params: { status: some_status }) .execute(Issue.find(id)) # Direct work item path: a WorkItem. DOES publish WorkItems::StatusChangedEvent. WorkItems::UpdateService.new(container: project, current_user: user, params: { status: some_status }) .execute(WorkItem.find(id)) ``` Passing `status` through `params` rather than `widget_params` in both calls isolates the single variable that matters here, the class of the object handed to the callback. `WidgetableService` merges `params.slice(*ALLOWED_PARAMS)` into the callback params (`app/services/concerns/work_items/widgetable_service.rb:21`), so this is equivalent to the production `widget_params: { status_widget: { status: ... } }` path. ### What is the current *bug* behavior? The status change from a board drag is persisted and visible in the UI, but `WorkItems::StatusChangedEvent` is not published. `Ai::Catalog::Flows::ExecuteWorkItemStatusChangedWorkflowTriggersWorker` therefore never runs, and any `work_item`/`status_changed` flow trigger is silently skipped with no error. ### What is the expected *correct* behavior? A status change caused by a board drag should publish `WorkItems::StatusChangedEvent` the same way a direct status change on the work item does, so flow triggers fire consistently regardless of which UI path changed the status. ### Root cause The publish guard lives in `after_update_commit`: ```ruby # ee/app/services/work_items/callbacks/status.rb:34 def after_update_commit current_status = work_item.current_status return unless current_status changed = current_status.previous_changes.slice('custom_status_id', 'system_defined_status_id') return if changed.empty? publish_status_changed_event end ``` This guard infers "did the status change?" from the in-memory `previous_changes` on the `current_status` record the callback holds. That only works when the status was written directly onto the same object the callback holds a reference to. The chain that breaks it during a board drag: 1. The `issueMoveList` mutation (`app/graphql/mutations/boards/issues/issue_move_list.rb`) resolves the issuable through `IssuesFinder`, so the callback ends up operating on a plain `Issue`, not a `WorkItem`. 1. `Boards::Issues::MoveService#update` (`app/services/boards/issues/move_service.rb:54`) passes `status:` into `Issues::UpdateService`. The `status(issue)` param is computed in `ee/app/services/ee/boards/issues/move_service.rb:58` and `:90`. `WorkItems::Callbacks::Status` is registered as a callback for `Issues::UpdateService` in `ee/app/services/ee/issues/base_service.rb:14`, so `after_update` runs and the status genuinely does change. This is why the board UI shows the new status. 1. Inside that callback, `WorkItems::Widgets::Statuses::UpdateService#ensure_work_item` (`ee/app/services/work_items/widgets/statuses/update_service.rb:97`) sees it was handed an `Issue`, so it loads a separate, fresh `WorkItem` instance and writes the new status onto that object instead of the `Issue`. 1. `sync_original_association` (`ee/app/services/work_items/widgets/statuses/update_service.rb:75`, called from line 34) then calls `@original.association(:current_status).reset` on the original `Issue`, so its `current_status` association is reloaded from the database. 1. Back in `after_update_commit`, `work_item.current_status` re-reads from the database. A freshly loaded record has an empty `previous_changes`, so the guard returns early and no event is published. Changing status directly on a work item works because it goes through `WorkItems::UpdateService` with an actual `WorkItem`. `ensure_work_item` returns that same object, `sync_original_association` is a no-op, `previous_changes` stays populated, and the event fires. This asymmetry is partially documented already. The comment at `ee/app/services/work_items/widgets/statuses/update_service.rb:70-74` notes that the sync is a "No-op when the caller passed the same object we wrote to (WorkItem callers), which preserves the `previous_changes` their `after_update_commit` callbacks depend on." It just does not account for the `Issue`-caller case. `sync_original_association` was added in `360092d47af6` ("Reset current_status association after state-change status update") to fix a webhook payload bug, https://gitlab.com/gitlab-org/gitlab/-/work_items/604714. That fix is correct for the webhook path, but it leaves the event-publishing guard broken for `Issue` callers. The `#after_update_commit` specs in `ee/spec/services/work_items/callbacks/status_spec.rb:326` only build the callback with `create(:work_item, ...)`, never with a plain `Issue`, so this path is untested. ### Possible fixes Primary option: hand the original caller the record that was just written instead of forcing a reload. This preserves both the webhook fix and `previous_changes`. ```ruby # ee/app/services/work_items/widgets/statuses/update_service.rb:75 def sync_original_association return if @original.equal?(work_item) return unless @original.respond_to?(:current_status) @original.association(:current_status).target = work_item.current_status end ``` With this, `status_with_fallback` on the `Issue` still returns the new value, and `previous_changes` on `current_status` stays intact, so `after_update_commit` publishes the event. Alternative: stop inferring the change from `previous_changes` entirely. Have `Statuses::UpdateService#execute` explicitly report whether it wrote a new status, and have the callback carry that result from `after_update` to `after_update_commit`. More churn, but it removes the object-identity coupling instead of patching this one instance of it. Either fix should ship with a spec that exercises `WorkItems::Callbacks::Status#after_update_commit` with a plain `Issue` as the callback's object, not just a `WorkItem`. ### Output of checks The root cause was confirmed by reading the code on `master` at commit `9e994f216da9`. The original report came from a local branch, and the behaviour has not yet been verified on GitLab.com. Nothing in the affected chain is behind a feature flag, so it is expected to reproduce there. ### Related issues - https://gitlab.com/gitlab-org/gitlab/-/work_items/607577 covers a separate reason a `status` filter on this trigger fails: `filter_data` in `ee/app/workers/concerns/ai/cloud_events_flow_trigger_worker.rb:76` only carries `action`, never the status name. Anyone hitting the board-drag bug described here while also using a status filter is likely hitting both. - https://gitlab.com/gitlab-org/gitlab/-/work_items/607576 covers only one trigger firing when several share the `Work item → Status changed` event type, which is relevant to the same "one trigger per stage" setup. - https://gitlab.com/gitlab-org/gitlab/-/work_items/603809 is the feedback issue for this trigger. ### Notes - Scope: any other code path that changes a work item's status through `Issues::UpdateService` with a plain `Issue`, rather than `WorkItems::UpdateService` with a `WorkItem`, is likely affected by the same root cause. Board drag is the reported symptom, not necessarily the only one. Other paths have not been enumerated or verified here. - Separate and possibly intentional, flagged only because it affects the same users: `ee/app/services/ee/boards/issues/move_service.rb:90` only computes a status when the target list is a status list, or when moving from a status list to the backlog or closed list. Dragging from a status list to a label list passes `status: nil`, so the status is left unchanged. Out of scope for this issue. - The symptom is in Duo Agent Platform triggers, but the fix lands in work item status code, so this may need to move to whichever group owns `ee/app/services/work_items/widgets/statuses/`.