Repository navigation
fix(watch): Keep portal lists fresh after create, update and delete - #1633
Merged
Merged
Conversation
🧪 Test Summary
Need another run? Use Re-run failed jobs: one shard costs a few minutes, the whole workflow about 26. |
yahyafakhroji
force-pushed
the
fix/watch-reliability
branch
from
October 6, 2026 00:46
0c3255b to
457b67c
Compare
🧪 Test Summary
Need another run? Use Re-run failed jobs: one shard costs a few minutes, the whole workflow about 26. |
yahyafakhroji
force-pushed
the
fix/watch-reliability
branch
from
October 6, 2026 01:08
457b67c to
ae51501
Compare
🧪 Test Summary
Need another run? Use Re-run failed jobs: one shard costs a few minutes, the whole workflow about 26. |
Upstream watches could end while idle and never restart, missed events were never signalled, and a subscribe that landed on the other replica failed for good. The hub now restarts and backs off upstreams per user, sends a resync event whenever a channel may have missed changes, and can relay subscribes through Redis behind WATCH_RELAY_ENABLED.
Lists stayed stale until a hard refresh: the client never refetched after its stream dropped or the hub reported a gap, pages served cached lists without refetching, and some mutations left their list to a watch that had already unmounted. The client now resyncs every watched query after any gap, every resource writes its own list on create, update and delete, and tables show pending, changed and reconnecting states.
yahyafakhroji
force-pushed
the
fix/watch-reliability
branch
from
October 6, 2026 02:27
ae51501 to
d20d91a
Compare
🧪 Test Summary
Need another run? Use Re-run failed jobs: one shard costs a few minutes, the whole workflow about 26. |
mattdjenkinson
approved these changes
Oct 6, 2026
This was referenced Oct 6, 2026
mattdjenkinson
added a commit
that referenced
this pull request
Oct 6, 2026
…1640) **Problem** The org projects list sometimes showed projects from other organizations. They flashed in, then disappeared on their own or after a refresh. Milo's org-scoped project watch wasn't filtered by organization, so it streamed every org's projects. Before #1633 the portal never applied ADDED events to the projects list, so this went unnoticed. Now that watch events write into the list, the replay sent on each subscribe added other orgs' projects until the next REST refetch removed them. **Solution** The root cause is fixed in Milo in milo-os/milo#828. This PR is a backstop so the portal never trusts the stream's scoping by itself. Watch caches can now take an `accepts` check, and the project list watch drops any project whose `organizationId` isn't the org being viewed. I deliberately didn't make the watch apply the REST list's Ready filter, because that would stop newly created projects showing while they provision. A unit test covers another org's ADDED being ignored and the org's own projects still being added; it fails without the guard.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Lists and detail pages in the portal could stay stale until a hard refresh. The client never refetched after its live stream dropped, the tab was hidden, or the hub missed events. List pages served cached data without refetching, and some mutations left their list to a watch that had already unmounted. On the server, upstream watches could die silently, and a subscribe that landed on the other replica failed for good.
Solution
The client resyncs every watched query after any gap and treats data as fresh only while it's watched. Every resource writes its own list on create, update and delete, with optimistic rows and "Deleting…" until the server confirms. The hub restarts upstreams per user, tells clients when a channel may have missed changes, and can relay subscribes across pods through Redis behind
WATCH_RELAY_ENABLED, which is off by default. Tables show pending and changed rows, and a header notice appears only while live updates are delayed.How to test
bun testand the component specs pass. In the portal, delete a resource from its detail page and go back to the list, or hide the tab while another session changes a resource and return to it: the list updates without a refresh.Preview
Create secret
Reconnect Indicator
Two tab live update
Closes #1630
Refs #1614