Repository navigation
fix(client): prevent stale reads from restoring deleted sessions - #56886
Kyle-j-bush wants to merge 2 commits into
Conversation
|
The following comment was made by an LLM, it may be inaccurate: |
![opencode-agent[bot]](https://avatars.githubusercontent.com/in/1549082?s=60&v=4){kind=small}
There was a problem hiding this comment.
I found no problems that should block a merge. On the base, the reproduction from #56736 (real createData and generated client, with a mocked fetch and an in-memory event bus) brings back the deleted session both after a delayed metadata read and after a delayed family read. With this change, both stay deleted, and a later sync of the deleted child sends its own request again. The packages/client tests (231) and the type check pass.
I also checked the timing cases. When a sync is skipped because a read is already running, or waits for an earlier read to finish, deletions are still caught by the read that actually runs. A deleted parent's family read is not marked complete. A delete that arrives after the response is written still removes the session.
Public API: unchanged (internal to createData).
One small point on the new test: the test.each over metadata/family repeats kind === "family" in about seven places (fetch routing, fixtures, assertions), which makes it hard to follow. Two short plain tests would be clearer.
|
Split the test into two different test following the comment from the bot |
Issue for this PR
Closes #56736
Type of change
What does this PR do?
Ignore sessions deleted while metadata or family reads are in flight. Deletions are tracked only until each read settles, preventing stale responses from restoring deleted records or marking them synchronized.
How did you verify your code works?
bun run checkpasses, with existing lint warnings.Screenshots / recordings
No visual layout change.
Checklist