refactor(runtime): remove legacy timestamp session read marker - #3080
Conversation
Remove the unused timestamp-based Session read path so Runtime Host message identity remains the sole read-state mutation authority. Generated-by: Codex
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (7)
💤 Files with no reviewable changes (7)
📝 WalkthroughSummaryThis PR removes the unused timestamp-based Session read-marker path from Runtime and storage.
The change is the smallest coherent solution. It removes the obsolete API, its persistence implementation, and test-only hooks. The deleted fixtures and interleaving hook can remain deleted because they only supported the removed timestamp path and do not weaken coverage of message-ID read-state behavior. Validation includes typecheck, formatting, and focused storage tests. Full Runtime and Storage suites remain unverified because unrelated Windows and Runtime Host issues block them. Review-relevant risksThe diff changes internal and exported Runtime and storage contracts by removing timestamp-based read-marker methods. Callers that still use these methods require migration to the Runtime Host message-ID operation. Any material public-contract effect requires independent human review under repository policy. No other protected-area effect was identified in the current diff. The person performing the merge must review the final diff, and a maintainer makes the final determination. WalkthroughThe legacy timestamp-based session read-marker path was removed from runtime contracts, session management, storage wiring, and test fixtures. Message-ID-based read-marker handling remains available. ChangesTimestamp read-marker removal
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This localized refactor removes an unused timestamp-based read-marker path while retaining message-ID authority; no actionable merge-blocking risk remains beyond normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Astro-Han
left a comment
There was a problem hiding this comment.
Reviewed exact head 5fc541124aa138ea5abe73df10f65ca706e31f2f. No P0–P3 findings.
The removal is complete and leaves Runtime Host message identity as the sole durable Session read-marker authority. I verified that no timestamp callers or compatibility paths remain, the deleted test hooks only served the removed path, and the message-ID production chain and its focused coverage remain intact. All required checks are green.
Disclosure: I used Codex to assist with source tracing and independent review passes. I reviewed the evidence and final diff and own this approval.
Summary
Remove the unused timestamp-based Session read-marker path from Runtime and storage. Runtime Host message identity remains the sole authority for mutating
lastReadMessageIdandhasUnread.Fixes #3072
Verification
npm --workspace @maka/runtime run typechecknpm --workspace @maka/storage run typechecknpm run format:checknode --test dist/__tests__/session-store.test.jsinpackages/storage(16/16 passed)markSessionReadThroughMessage()Full Runtime and Storage suites were attempted on Windows. They remain blocked by unrelated existing Windows symlink,
fsutil, PowerShell, PTY, and path-containment failures. Runtime Host build is independently blocked by the existing implicit-anyerror atsrc/server/session-transcript-pager.ts:249.Breaking change
Embedded legacy Runtime compositions can no longer mark a Session read using only a timestamp. Callers must use the supported Runtime Host message-ID operation.
AI use
Select exactly one:
Tool(s) and scope: Codex assessed issue #3072, removed the legacy Runtime/storage timestamp path and related test-double code, and assisted with verification and review. The commit includes the required
Generated-by: Codextrailer.Checklist
Does this PR entail a change in behavior?