Repository navigation
fix(mothership): drop queued tab adds the server already removed - #9050
Conversation
A server-applied remove effect cleared the tab locally but left the client's queued add for the same resource in the persistence queue, so the next flush re-posted it and hydration re-projected the tab. The deleted resource then went out as an open tab on every later message. The remove effect now discards that pending add (the server already removed it, so no client delete is sent). Active-tab resolution now logs a missing resource at info and a revoked one at warn instead of error; other failures still log at error.
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
There was a problem hiding this comment.
All reported issues were addressed across 8 files
Reply with feedback, questions, or to request a fix.
Turn on auto-fix | Re-trigger cubic
[Medium impact] The PR appears safe to merge within its stated scope. SummaryThe PR drops queued or failed resource adds when a server removal arrives, live or through reconnect replay.
|
… tabs An add already in flight when the server's removal arrives can commit after it, so the queue now schedules a compensating delete ordered after that write settles. Queued or failed adds are still dropped with no delete. Recovered remove effects (replay or deferred batch) now discard the queued add too; previously the recovery path returned before the discard ran.
|
@greptileai review |
|
@cubic-dev-ai review |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
There was a problem hiding this comment.
All reported issues were addressed across 8 files
Reply with feedback, questions, or to request a fix.
Turn on auto-fix | Re-trigger cubic
|
@greptileai review |
An upsert effect means the server stored the resource again, so a client delete still waiting behind an in-flight add must not run. The queue drops that removal the same way a newer add does; nothing is written since the server already holds the resource.
|
@greptileai review |
|
@cubic-dev-ai review |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
|
@greptileai review |
|
@cubic-dev-ai review |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
There was a problem hiding this comment.
All reported issues were addressed across 8 files
Reply with feedback, questions, or to request a fix.
Turn on auto-fix | Re-trigger cubic
Drops the in-flight compensating delete and the restore cancel path: each added a new client/server ordering hazard. A server remove effect, live or on recovery, now only discards a queued or failed client add for that resource; a write already in flight is left untouched.
|
@greptileai review |
|
@cubic-dev-ai review |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
|
@greptileai review |
|
@cubic-dev-ai review |
@waleedlatif1 I have started the AI code review. It will take a few minutes to complete. |
Summary
Type of Change
Testing
use-chatDOM regression tests: a failed add followed by a server remove effect, delivered live and via a reconnect replay. Before the fix the add is re-posted, the tab comes back and the deleted id is sent as an attachment; after the fix none of that happensprocess-contentstest covering info/warn/error per failure classChecklist