### Summary When an MR page is open in the browser, award emoji reactions (and other note-level changes) added by external services via the REST API are not reflected in real-time. The UI only updates after a full page reload. The backend persists the change correctly and ActionCable events are published, but the frontend store does not update. This is a regression introduced in 17.10 by !181396 ("Improve syncWithVuex plugin performance"), confirmed working in 18.7.2 and broken from 18.8.x onward. ### Steps to reproduce 1. Open a merge request page in the browser as user A 2. As a separate service account / via `curl`, call: `POST /api/v4/projects/:id/merge_requests/:iid/notes/:note_id/award_emoji?name=thumbsup` 3. Observe the MR page — the award emoji does **not** appear without a page reload 4. Reload the page — the emoji is now visible, confirming it was persisted ### Example Project Any project with an MR. Reproduced via Atlantis automation on a Self-Managed instance running 18.10.5. ### What is the current *bug* behavior? Award emoji reactions (and other note-level changes) added via the API by external services do not appear on an already-open MR page. The browser refetches `/noteable/merge_request/:id/notes` and `/merge_requests/:iid/discussions.json` (triggered by ActionCable), but the UI is not updated. A full page reload is required to see the changes. Changes made by the **currently logged-in user** are unaffected. ### What is the expected *correct* behavior? Award emoji reactions and note updates added via the API should appear in real-time on open MR pages, consistent with behaviour prior to 17.10. ### Relevant logs and/or screenshots Log timeline showing the full sequence: - `POST /award_emoji` → `status=201`, `redis_action_cable_calls=2` ✅ (backend correct) - Browser refetches `/noteable/.../notes` → `status=200` ✅ - Browser refetches `/discussions.json` → `status=304` then `200` ✅ - MR page does **not** render the new emoji ❌ - Full page reload → emoji visible ✅ ### Output of checks <details> <summary>Expand for output related to GitLab environment info</summary> <pre> Self-Managed, Linux package (Omnibus), GitLab 18.10.5 (Premium) </pre> </details> <details> <summary>Expand for output related to the GitLab application check</summary> <pre> Not provided </pre> </details> ### Possible fixes The regression was introduced by !181396 ("Improve syncWithVuex plugin performance", 17.10), which changed the `syncWithVuex` Pinia plugin from syncing the entire Vuex state on every mutation to only replaying named mutations that exist in both stores. For externally-triggered note updates, `updateOrCreateNotes()` calls `UPDATE_NOTE` / `ADD_NEW_NOTE` on the Pinia `useNotes` store, but the corresponding mutation name (e.g. `notes/UPDATE_NOTE`) is not registered in `vuexStore._mutations`. Because MR page Vue components still read from the Vuex store during the migration, the UI never receives the update — it is silently dropped. The fix should ensure that note mutations triggered by `fetchUpdatedNotes()` (the ActionCable real-time path) are correctly propagated back to the Vuex store, or that the consuming components read from Pinia directly. Related: - !181396 — breaking change (17.10) - !178302 — prerequisite change (17.9) ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) for information about the next patch release, including the targeted versions, expected release date, and current status.