Issue status change not pushed over SSE to project boards containing that issue #19

New Issue

2026-05-17T20:45:18+03:00

oleks commented

2026-05-17 20:45:18 +03:00

Summary: When an issue's state changes (open → closed, or reopened), the project/kanban boards that contain that issue as a card do not receive the update over the SSE (server-sent events) stream. The board keeps showing the issue in its old column/state until the page is manually reloaded. The change is persisted correctly server-side — only the live push to subscribed board views is missing.

Observed behavior:

Open a project board (user/org/repo-level Projects) that has issue X placed on it.
In another view (or via API), close or reopen issue X.
The open board view does not move the card / does not reflect the new state. A full page reload is required to see the correct column/status.

Expected behavior:

Closing/reopening an issue should emit an SSE event that every board containing that issue is subscribed to, so the card moves to the correct column (or its rendered state updates) live, without a reload — consistent with how other live board mutations behave.

Likely area to investigate:

The events/notification publisher on the issue state-change path (issue close/reopen service) — confirm whether it emits an SSE/eventsource message scoped to the project board channels the issue belongs to, or only to the issue/repo timeline channel.
The project board's SSE subscription: which channels/topics it listens on, and whether issue-state-change events are among them. The board likely subscribes to project-scoped events but the issue state-change only publishes on an issue/repo-scoped topic, so boards never receive it.
Cross-check whether adding/removing a card or moving a column does push over SSE correctly (it appears to) — the gap seems specific to the issue open/closed state transition not being fan-out to project board subscribers.
Determine if this is fork-introduced (the fork carries project-board API/feature work) or inherited upstream behavior.

Impact: Boards used as live dashboards show stale issue state; automation/humans watching a board don't see closures until reload. Low severity (no data loss — DB and non-board views are correct), but it undermines the board's usefulness as a live view and is the kind of staleness that compounds with the counter-staleness already tracked.

Related: oleks/gitea#16 (stale open_issues_count in /user/repos) — both are "a derived/projected view isn't invalidated on issue state change," though that one is a counter and this one is the SSE board push.

Severity: low (UX/observability; state is correct on reload and in the DB).

**Summary:** When an issue's state changes (open → closed, or reopened), the project/kanban boards that contain that issue as a card do not receive the update over the SSE (server-sent events) stream. The board keeps showing the issue in its old column/state until the page is manually reloaded. The change is persisted correctly server-side — only the live push to subscribed board views is missing. **Observed behavior:** - Open a project board (user/org/repo-level Projects) that has issue X placed on it. - In another view (or via API), close or reopen issue X. - The open board view does not move the card / does not reflect the new state. A full page reload is required to see the correct column/status. **Expected behavior:** - Closing/reopening an issue should emit an SSE event that every board containing that issue is subscribed to, so the card moves to the correct column (or its rendered state updates) live, without a reload — consistent with how other live board mutations behave. **Likely area to investigate:** - The events/notification publisher on the issue state-change path (issue close/reopen service) — confirm whether it emits an SSE/eventsource message scoped to the project board channels the issue belongs to, or only to the issue/repo timeline channel. - The project board's SSE subscription: which channels/topics it listens on, and whether issue-state-change events are among them. The board likely subscribes to project-scoped events but the issue state-change only publishes on an issue/repo-scoped topic, so boards never receive it. - Cross-check whether *adding/removing* a card or *moving* a column does push over SSE correctly (it appears to) — the gap seems specific to the issue open/closed state transition not being fan-out to project board subscribers. - Determine if this is fork-introduced (the fork carries project-board API/feature work) or inherited upstream behavior. **Impact:** Boards used as live dashboards show stale issue state; automation/humans watching a board don't see closures until reload. Low severity (no data loss — DB and non-board views are correct), but it undermines the board's usefulness as a live view and is the kind of staleness that compounds with the counter-staleness already tracked. **Related:** oleks/gitea#16 (stale `open_issues_count` in `/user/repos`) — both are "a derived/projected view isn't invalidated on issue state change," though that one is a counter and this one is the SSE board push. Severity: low (UX/observability; state is correct on reload and in the DB).

oleks added the area/milestone-sse kind/backend labels 2026-05-17 20:45:18 +03:00

oleks referenced this issue from a commit

2026-05-17 20:58:27 +03:00

fix(project): push SSE update when an issue on a board is closed/reopened

oleks referenced a pull request that will close this issue

2026-05-17 20:59:41 +03:00

fix(project): push SSE update when an issue on a board is closed/reopened #20

oleks closed this issue

2026-05-17 20:59:50 +03:00

Sign in to join this conversation.