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

Share the Find Work catalog refresh across application workers #453

New Issue
Closed
opened 2026-08-10 04:29:03 +00:00 by timmy · 0 comments
timmy commented 2026-08-10 04:29:03 +00:00
Owner
Copy Link

Problem

The Find Work catalog uses process-local cache and single-flight state. In a multi-worker deployment, each worker can independently scan up to ten Gitea pages every 15 seconds, consuming the bounded upstream read pool and serving divergent claim state.

Vertical slice

Persist the available-issue snapshot, retry metadata, and an expiring refresh lease in shared SQLite state. One worker refreshes while peers immediately serve the retained snapshot with truthful stale/revalidating/failure metadata. Confirmed claims invalidate the shared catalog for every worker.

Acceptance tests

  • Two independent worker stores sharing one database allow exactly one expired-catalog refresh lease.
  • A peer serves retained results immediately while the owner refreshes.
  • Published results and confirmed-claim removals are visible across workers.
  • Refresh failure creates shared backoff, and an abandoned lease is recoverable after expiry.
  • SQLite work runs off the event loop and the full suite remains green.

Evidence

Current src/main.py keeps _available_issue_snapshot_* entirely in process memory, while gitea_proxy.available_issue_snapshot() can scan ten pages. Historical #213 covers same-process stale-while-revalidate and #433 covers shared live snapshots, not Find Work. No open or historical issue title or recent commit implements a worker-shared available-work catalog.

## Problem The Find Work catalog uses process-local cache and single-flight state. In a multi-worker deployment, each worker can independently scan up to ten Gitea pages every 15 seconds, consuming the bounded upstream read pool and serving divergent claim state. ## Vertical slice Persist the available-issue snapshot, retry metadata, and an expiring refresh lease in shared SQLite state. One worker refreshes while peers immediately serve the retained snapshot with truthful stale/revalidating/failure metadata. Confirmed claims invalidate the shared catalog for every worker. ## Acceptance tests - Two independent worker stores sharing one database allow exactly one expired-catalog refresh lease. - A peer serves retained results immediately while the owner refreshes. - Published results and confirmed-claim removals are visible across workers. - Refresh failure creates shared backoff, and an abandoned lease is recoverable after expiry. - SQLite work runs off the event loop and the full suite remains green. ## Evidence Current `src/main.py` keeps `_available_issue_snapshot_*` entirely in process memory, while `gitea_proxy.available_issue_snapshot()` can scan ten pages. Historical #213 covers same-process stale-while-revalidate and #433 covers shared live snapshots, not Find Work. No open or historical issue title or recent commit implements a worker-shared available-work catalog.
timmy self-assigned this 2026-08-10 04:29:03 +00:00
timmy closed this issue 2026-08-10 04:44:58 +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#453
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?