Live-update the global /issues index when issues change anywhere #14

Closed AtlantisPleb opened this 8h ago 1 comment

Outcome

The cross-repository issue index at /issues updates in place, through LiveView, when any issue the viewer can read is created or changed — including issues created from another surface such as the API or a different repository's page.

Evidence

Creating an issue via the API on 2026-08-22 did not appear on /issues until a manual reload. The repository-scoped index subscribes to {:issues_changed, repository_id} and re-reads on every committed write; the global index has no equivalent subscription, so it renders one snapshot at mount.

Work

Broadcast an issue-change notification for every committed issue write (create, update, close, reopen), not only writes made through the web UI.
Subscribe the global /issues LiveView to those notifications and re-run list_visible_issues_page/2 under the current viewer's authorization when one arrives.
Re-stream with reset: true, and keep counts and filter results consistent with the new page.
Throttle or coalesce bursts so a batch import does not produce one reload per issue.
Verify that a private-repository issue never reaches a viewer who cannot read it: the refresh path must apply the same readable_by predicate as the initial load.

Acceptance criteria

An issue created over the API appears on /issues within one broadcast cycle without a page reload.
Closing, reopening, and editing behave the same way.
Viewers without access see no row for a private issue at any point.
A burst of N writes triggers a bounded number of re-reads, not N.

Verification

LiveView tests asserting stream updates after out-of-band writes, an authorization test with a private repository, and mix precommit.

AtlantisPleb opened this issue 8h ago
A AtlantisPleb Author 7h ago
Implemented and on main (f05131a).
- Repositories.broadcast_issues/1 now also announces on a global issues:all topic; the /issues workspace subscribes at mount.
- Each announcement re-reads the current page through the viewer's own authorization — the same readable_by predicate as the initial load — so an API-created issue appears within one broadcast cycle and a private issue never surfaces for a viewer who cannot read it.
- Bursts coalesce: every change re-arms one 250 ms timer, so N writes cost one re-read, not N. Tests run at zero debounce with a synchronous refresh path.
LiveView tests cover out-of-band creation, burst convergence, and private-repo isolation for both signed-in members and outsiders.
closed this as completed 7h ago