Context
This issue started as "Add SSE event ordering tests for browser mode sync" but evolved during implementation when we discovered a critical architectural insight:
NodeSpace already uses explicit event emission from the business logic layer, NOT SurrealDB LIVE SELECT queries.
The LiveQueryService name is misleading because:
- It does NOT use SurrealDB's
LIVE SELECT feature
- It subscribes to domain events from
SurrealStore (explicit business logic events)
- Events are emitted by application code after CRUD operations, not by database triggers
This explicit event emission approach is actually the correct design for NodeSpace because it provides:
- Precise control over event timing and content
- Guaranteed event ordering within transactions
- No dependency on SurrealDB's LIVE SELECT latency
- Ability to emit events only for meaningful domain changes
Architectural Decision
Explicit Event Emission vs. LIVE SELECT
| Approach |
Description |
Status |
| LIVE SELECT |
Database automatically emits events for any table change |
Not used |
| Explicit Emission |
Application code emits domain events after operations |
Current implementation |
Why Explicit Emission is Correct for NodeSpace:
- Event Ordering: Events are emitted in the correct order by the business logic, not subject to database trigger ordering
- Semantic Events: We emit domain-meaningful events (e.g.,
EdgeRelationship::Hierarchy) not raw table changes
- Transaction Boundaries: Events can be emitted at the end of complex operations, not after each intermediate step
- Performance: No database polling or trigger overhead
- Testability: Events can be easily mocked and verified in tests
The architecture documentation (hierarchy-reactivity-architecture-review.md) has been updated with a warning that clarifies this distinction.
Completed Work
Remaining Work
1. Rename LiveQueryService to DomainEventForwarder or EventBridgeService
Acceptance Criteria:
Why: The current name implies SurrealDB LIVE SELECT queries, which is not what the service does. It forwards domain events from the business logic layer to the Tauri frontend.
2. Update Reactive Store Comments
Acceptance Criteria:
Why: Comments referencing "LIVE SELECT" are misleading for future developers.
3. Audit Transaction Boundaries in Complex Operations
Acceptance Criteria:
Why: Complex operations like move_node should emit a single atomic event, not intermediate states.
4. Add Unit Tests for Event Emission Per Operation
Acceptance Criteria:
Why: Ensures the explicit event emission contract is documented and enforced via tests.
Acceptance Criteria (Overall)
For this issue to be considered complete:
- Service renamed with accurate terminology reflecting explicit event emission
- All comments and documentation updated to remove LIVE SELECT references
- Transaction boundaries audited with findings documented
- Unit tests added for event emission per operation
- All existing tests continue to pass
Branch Name
Current: feature/issue-643-sse-event-ordering-tests
Suggested: feature/issue-643-event-architecture-cleanup
Related Documentation
/docs/architecture/development/hierarchy-reactivity-architecture-review.md - Architecture decision record
/packages/core/src/db/events.rs - Domain event definitions
/packages/desktop-app/src-tauri/src/services/live_query_service.rs - Service to rename
/packages/desktop-app/src/tests/services/browser-sync-service.test.ts - New SSE ordering tests (12 tests)
Technical Notes
Event Flow (Current Implementation):
SurrealStore.create_node()
→ Emits DomainEvent::NodeCreated via broadcast channel
→ LiveQueryService (DomainEventForwarder) receives event
→ Forwards to Tauri frontend via app.emit("node:created", ...)
→ BrowserSyncService receives SSE/Tauri event
→ Updates SharedNodeStore and ReactiveStructureTree
This is NOT:
SurrealDB LIVE SELECT * FROM node
→ Database triggers emit events automatically
→ Events forwarded to frontend
Context
This issue started as "Add SSE event ordering tests for browser mode sync" but evolved during implementation when we discovered a critical architectural insight:
NodeSpace already uses explicit event emission from the business logic layer, NOT SurrealDB LIVE SELECT queries.
The
LiveQueryServicename is misleading because:LIVE SELECTfeatureSurrealStore(explicit business logic events)This explicit event emission approach is actually the correct design for NodeSpace because it provides:
Architectural Decision
Explicit Event Emission vs. LIVE SELECT
Why Explicit Emission is Correct for NodeSpace:
EdgeRelationship::Hierarchy) not raw table changesThe architecture documentation (
hierarchy-reactivity-architecture-review.md) has been updated with a warning that clarifies this distinction.Completed Work
hierarchy-reactivity-architecture-review.mdRemaining Work
1. Rename
LiveQueryServicetoDomainEventForwarderorEventBridgeServiceAcceptance Criteria:
packages/desktop-app/src-tauri/src/services/live_query_service.rstodomain_event_forwarder.rsLiveQueryServicetoDomainEventForwardermod.rsandlib.rsWhy: The current name implies SurrealDB LIVE SELECT queries, which is not what the service does. It forwards domain events from the business logic layer to the Tauri frontend.
2. Update Reactive Store Comments
Acceptance Criteria:
packages/desktop-app/src/lib/stores/reactive-structure-tree.svelte.tsfor LIVE SELECT referencespackages/desktop-app/src/lib/services/browser-sync-service.tsfor LIVE SELECT referencesWhy: Comments referencing "LIVE SELECT" are misleading for future developers.
3. Audit Transaction Boundaries in Complex Operations
Acceptance Criteria:
move_nodeoperation to verify single domain event emitted at endindent_nodeandoutdent_nodefor proper event batchingWhy: Complex operations like
move_nodeshould emit a single atomic event, not intermediate states.4. Add Unit Tests for Event Emission Per Operation
Acceptance Criteria:
create_nodeemitsNodeCreated+EdgeCreatedeventsupdate_nodeemitsNodeUpdatedeventdelete_nodeemitsEdgeDeleted+NodeDeletedevents (in correct order)move_nodeemits appropriate edge eventsWhy: Ensures the explicit event emission contract is documented and enforced via tests.
Acceptance Criteria (Overall)
For this issue to be considered complete:
Branch Name
Current:
feature/issue-643-sse-event-ordering-testsSuggested:
feature/issue-643-event-architecture-cleanupRelated Documentation
/docs/architecture/development/hierarchy-reactivity-architecture-review.md- Architecture decision record/packages/core/src/db/events.rs- Domain event definitions/packages/desktop-app/src-tauri/src/services/live_query_service.rs- Service to rename/packages/desktop-app/src/tests/services/browser-sync-service.test.ts- New SSE ordering tests (12 tests)Technical Notes
Event Flow (Current Implementation):
This is NOT: