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

Refresh Human Gates atomically on every reopen #1433

New Issue
Closed
opened 2026-08-26 13:33:29 +00:00 by timmy · 0 comments
timmy commented 2026-08-26 13:33:29 +00:00
Owner
Copy Link

Problem

Closing and reopening Human Gates does not establish a fresh review session. Before optional hydration, reopen only unhides stale state. After hydration, the queue reloads while the fixed review snapshot can still point to an older candidate, so selecting a newly rendered gate throws Gate is not in the current review snapshot.

User impact

A release operator returning to the inbox can review an obsolete candidate, miss a new release gate, or be unable to open a gate shown in the list. Candidate-hash freshness is part of the safety boundary.

Acceptance

  • close → replace server queue → reopen performs exactly one fresh list request and list/detail/current all reference the new candidate
  • concurrent reopen calls coalesce into one request
  • progressive pre-hydration reopen refreshes instead of only unhiding
  • hydrated handoff reuses the same controller without duplicate requests
  • arrivals during an open review session do not mutate that fixed snapshot
  • failed reopen retains cached review data as non-authoritative and remains retryable
  • focused frontend and packaged mobile browser tests cover the reopen journey

Evidence / non-duplication

frontend/progressive-human-gates.js short-circuits once started; frontend/human-gates.js reloads queue without resetting an active reviewSnapshot. All historical issue titles and recent Human Gates commits were checked; none cover reopen-cycle freshness or queue/snapshot divergence.

## Problem Closing and reopening Human Gates does not establish a fresh review session. Before optional hydration, reopen only unhides stale state. After hydration, the queue reloads while the fixed review snapshot can still point to an older candidate, so selecting a newly rendered gate throws `Gate is not in the current review snapshot.` ## User impact A release operator returning to the inbox can review an obsolete candidate, miss a new release gate, or be unable to open a gate shown in the list. Candidate-hash freshness is part of the safety boundary. ## Acceptance - close → replace server queue → reopen performs exactly one fresh list request and list/detail/current all reference the new candidate - concurrent reopen calls coalesce into one request - progressive pre-hydration reopen refreshes instead of only unhiding - hydrated handoff reuses the same controller without duplicate requests - arrivals during an open review session do not mutate that fixed snapshot - failed reopen retains cached review data as non-authoritative and remains retryable - focused frontend and packaged mobile browser tests cover the reopen journey ## Evidence / non-duplication `frontend/progressive-human-gates.js` short-circuits once started; `frontend/human-gates.js` reloads queue without resetting an active `reviewSnapshot`. All historical issue titles and recent Human Gates commits were checked; none cover reopen-cycle freshness or queue/snapshot divergence.
timmy self-assigned this 2026-08-26 13:33:29 +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#1433
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?