fix: read loop watch-events with a stream-global cursor - #356

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

internal/loop/watch/output.go (1)

110-119: 🩺 Stability & Availability | 🔵 Trivial | 🏗️ Heavy lift

Consider a rearm path instead of a permanent error for an unsupported cursor version.

An unsupported cursor_version currently produces an error on every decode. Both known callers propagate it: evaluateWatchEventsNode in internal/loop/coordinator_watch_events.go returns it as a coordinator failure, and loopWatchEventsReadModel in internal/daemon/loop_api_watch_events.go fails the read model. A parked Loop in that state has no recovery path short of manual database repair.

An alternative is to treat an unknown version as "cursors are not usable", discard the stored cursors, and let recoverWatchEventsState rearm from the current stream position. That degrades to a hard cut for one run instead of blocking it. The current fail-closed behavior is defensible; record the operational recovery procedure if you keep it.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@internal/loop/watch/output.go` around lines 110 - 119, The unsupported
cursor-version branch in the pending-state decode should recover instead of
returning a permanent error: discard the stored cursors, retain the
subscriptions, and return state that allows recoverWatchEventsState to rearm
from the current stream position. Update the logic around EventsCursorVersion
and ensure both evaluateWatchEventsNode and loopWatchEventsReadModel can
continue through this recovery path.

internal/daemon/loop_run_events_e2e_integration_test.go (1)

965-971: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Split workspace creation out of the parity assertion helper.

assertWatchEventsReadModelParity asserts read-model parity across four transports, then creates a foreign workspace and returns its ID. The name states one responsibility; the function performs two. The caller at Line 256 has to write _ = assertWatchEventsReadModelParity(...) to discard a value it does not need.

Move the foreign-workspace creation and the 404 check into their own helper. The parity helper then returns nothing, and Line 256 reads cleanly.

♻️ Proposed split

-) string {
+) {
 	t.Helper()
 	...
-	foreignWorkspaceID := createWorkspaceViaUDS(t, ctx, harness, t.TempDir(), "foreign-workspace")
-	foreignPath := ...
-	...
-	return foreignWorkspaceID
 }
+
+func assertForeignWorkspaceLoopRunNotFound(
+	t testing.TB,
+	ctx context.Context,
+	harness *e2etest.RuntimeHarness,
+	runID string,
+) string {
+	t.Helper()
+	foreignWorkspaceID := createWorkspaceViaUDS(t, ctx, harness, t.TempDir(), "foreign-workspace")
+	// existing 404 assertion
+	return foreignWorkspaceID
+}

Then update Line 179 to call both, and Line 256 to call only the parity helper.

Also applies to: 1034-1051

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@internal/daemon/loop_run_events_e2e_integration_test.go` around lines 965 -
971, Split the foreign-workspace creation and 404 verification out of
assertWatchEventsReadModelParity into a separate helper that returns the
workspace ID. Change assertWatchEventsReadModelParity to return nothing while
retaining only the four-transport parity assertions, then update the callers so
the setup path invokes both helpers and the later call invokes only the parity
helper without discarding a return value.

internal/store/globaldb/global_db_watch_events_loop.go (1)

22-27: 🚀 Performance & Scalability | 🔵 Trivial | ⚖️ Poor tradeoff

Consider the scan cost of the cursor aggregate on large workspaces.

idx_loop_run_events_watch_stream covers (workspace_id, watch_seq), but the eligibility predicate filters on kind and on a json_extract of payload_json. SQLite cannot satisfy MAX(watch_seq) from the index under those filters, so this aggregate scans the full workspace partition of loop_run_events. The read path bounds its work with watch_seq > ? and LIMIT; the cursor path does not.

ReadCursors runs at arming time and during gap reconciliation, so the cost is bounded today. If the loop event ledger grows without pruning, add a descending scan bound or a retention sweep.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@internal/store/globaldb/global_db_watch_events_loop.go` around lines 22 - 27,
Bound the cursor aggregate in ReadCursors so it does not scan an unbounded
loop_run_events workspace partition. Prefer reusing or adding a retention sweep
for loop_run_events; alternatively apply a correct descending scan bound while
preserving the maximum eligible watch_seq result from
loopWatchEventsEligibilitySQL.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes