Fix transaction event sequencing and frontend deduplication #8

New issue

Closed

opened 2026-07-30 04:05:27 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-07-30 04:05:27 +00:00

(Migrated from github.com)

Problem

PR #3 emits every event in a multi-operation transaction with the same operation ID and the same workspace revision.

The frontend event bus drops an event when:

its operation ID was already seen; or
its revision is less than or equal to the last revision.

As a result, only the first event from a multi-operation transaction is delivered to subscribers. The remaining authoritative changes can be silently ignored by the UI.

The event bus also tracks one global revision across all workspaces and retains operation IDs without a bound.

Found during review of PR #3.

Required changes

Define explicit transaction event semantics.
Give each emitted event a unique event/operation identifier while preserving a shared transaction ID.
Include an ordered sequence number and total event count, or emit one authoritative transaction-committed event containing the complete result set.
Permit multiple events at the same committed revision.
Track revisions independently per workspace.
Bound or expire deduplication state.
Ignore events for workspaces the client is not currently subscribed to.
Add deterministic tests for duplicate delivery, out-of-order delivery, reconnect replay, and multiple events sharing a revision.

Suggested event shape:

{
  "event": "graph.node.created",
  "transactionId": "tx-123",
  "operationId": "tx-123:2",
  "workspace": "default",
  "revision": 14,
  "sequence": 2,
  "eventCount": 4,
  "payload": {}
}

Acceptance criteria

Every event from a successful multi-operation transaction reaches the frontend exactly once and in order.
Multiple events at the same revision are accepted.
Revisions from one workspace do not suppress another workspace's events.
Deduplication memory remains bounded.

Related PR: #3

## Problem PR #3 emits every event in a multi-operation transaction with the same operation ID and the same workspace revision. The frontend event bus drops an event when: - its operation ID was already seen; or - its revision is less than or equal to the last revision. As a result, only the first event from a multi-operation transaction is delivered to subscribers. The remaining authoritative changes can be silently ignored by the UI. The event bus also tracks one global revision across all workspaces and retains operation IDs without a bound. Found during review of PR #3. ## Required changes - Define explicit transaction event semantics. - Give each emitted event a unique event/operation identifier while preserving a shared transaction ID. - Include an ordered sequence number and total event count, or emit one authoritative transaction-committed event containing the complete result set. - Permit multiple events at the same committed revision. - Track revisions independently per workspace. - Bound or expire deduplication state. - Ignore events for workspaces the client is not currently subscribed to. - Add deterministic tests for duplicate delivery, out-of-order delivery, reconnect replay, and multiple events sharing a revision. Suggested event shape: ```json { "event": "graph.node.created", "transactionId": "tx-123", "operationId": "tx-123:2", "workspace": "default", "revision": 14, "sequence": 2, "eventCount": 4, "payload": {} } ``` ## Acceptance criteria - Every event from a successful multi-operation transaction reaches the frontend exactly once and in order. - Multiple events at the same revision are accepted. - Revisions from one workspace do not suppress another workspace's events. - Deduplication memory remains bounded. Related PR: #3