<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=590743) </details> <!--IssueSummary end--> Reported by @jiaan in `#is-this-known`. See this comment: https://gitlab.com/gitlab-org/glql/-/merge_requests/334#note_3093652577 It looks like the [note above](https://gitlab.com/gitlab-org/glql/-/merge_requests/334#note_3093273637) from @gitlab-bot was used as the "source" for the modification operation. It's not at all clear how this could happen — AFAICT this view is still using `task_list.js`, which in turn defers the operation to the _backend_ (which does read-modify-write of a single model object) — but let's keep an eye on it. If it was all on the frontend (using the `work_item_note_body` path) it would make more sense. I note that lately we sometimes get issues where work item notes seem to duplicate (perhaps as a result of weird ActionCable happenings? no idea), also occasionally reported in `#is-this-known` — I wonder if the state of which notes have which IDs ever gets messed up. Then all kinds of weird stuff could happen, theoretically.