stackchain/stackchain-dashboard
1
0
Fork 0
Code Issues 9 Pull Requests 1 Actions Packages Projects Releases 713 Wiki Activity

Coalesce live snapshot refreshes across application workers #433

New Issue
Closed
opened 2026-08-09 22:49:56 +00:00 by timmy · 0 comments
timmy commented 2026-08-09 22:49:56 +00:00
Owner
Copy Link

Problem

/api/v1/live keeps freshness, revision, retry, and refresh ownership in process-local globals. A multi-worker deployment therefore repeats the same seven-call Gitea refresh in every worker every freshness window, competing with foreground operator actions.

Vertical slice

Persist the live snapshot and an expiring refresh lease in the existing private state directory. All workers serve one shared snapshot while only the lease owner refreshes due sections. Preserve stale-while-revalidate, per-section retry/backoff, revision omission, and notification privacy behavior.

Acceptance tests

  • Two independent store instances racing for a cold refresh produce one lease winner and one upstream refresh.
  • A non-owner serves the shared stale snapshot immediately with revalidation state.
  • Atomic publication preserves unchanged section revisions and advances changed sections.
  • An expired lease can be recovered after a worker dies.
  • The store creates an owner-only SQLite file and persists no access token.
  • Existing focused and full test suites pass.

Evidence / non-duplication

Current origin/main uses process-local _live_snapshot_* globals in src/main.py; existing tests cover only in-process coalescing. Historical issues #131/#132, #137/#138, #139/#140, #285/#286, and #383/#384 do not provide cross-worker refresh ownership or a shared snapshot.

## Problem `/api/v1/live` keeps freshness, revision, retry, and refresh ownership in process-local globals. A multi-worker deployment therefore repeats the same seven-call Gitea refresh in every worker every freshness window, competing with foreground operator actions. ## Vertical slice Persist the live snapshot and an expiring refresh lease in the existing private state directory. All workers serve one shared snapshot while only the lease owner refreshes due sections. Preserve stale-while-revalidate, per-section retry/backoff, revision omission, and notification privacy behavior. ## Acceptance tests - Two independent store instances racing for a cold refresh produce one lease winner and one upstream refresh. - A non-owner serves the shared stale snapshot immediately with revalidation state. - Atomic publication preserves unchanged section revisions and advances changed sections. - An expired lease can be recovered after a worker dies. - The store creates an owner-only SQLite file and persists no access token. - Existing focused and full test suites pass. ## Evidence / non-duplication Current `origin/main` uses process-local `_live_snapshot_*` globals in `src/main.py`; existing tests cover only in-process coalescing. Historical issues #131/#132, #137/#138, #139/#140, #285/#286, and #383/#384 do not provide cross-worker refresh ownership or a shared snapshot.
timmy self-assigned this 2026-08-09 22:49:56 +00:00
timmy closed this issue 2026-08-09 23:21:59 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
P0

Drop everything

  
P1

High priority

  
P2

Medium priority

  
agent:nightprowl

Assignments routed to the LongCat NightProwl evaluation worker

  
backend

Backend service

  
ci

Continuous integration / actions

  
frontend

Frontend / UI

  
meta

Meta / planning

  
pages

Gitea Pages

  
template

Repo template / standards

No Label
P0
P1
P2
agent:nightprowl
backend
ci
frontend
meta
pages
template
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
timmy
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: stackchain/stackchain-dashboard#433
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?