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

Require fresh authorization before delivering queued issue closures #483

New Issue
Closed
opened 2026-08-10 12:20:01 +00:00 by timmy · 0 comments
timmy commented 2026-08-10 12:20:01 +00:00
Owner
Copy Link

Problem

Offline Queue close & next durably stores an issue-close operation, but automatic foreground/background drains submit it without the target-bound fresh authorization required by the close endpoint. In secure operator mode the server returns 428 and the delivery center misclassifies the intent as a generic failed delivery.

Product slice

Keep queued closure intent durable, but classify it as awaiting authorization. Never execute it from background or bulk automatic drains. Offer an explicit Authorize & close action that obtains a fresh grant for the exact issue and removes the queued operation only after confirmed closure.

Acceptance criteria

  • Background and automatic bulk drains skip queued issue-close records without marking them failed.
  • Delivery Center identifies closures as awaiting authorization and exposes an explicit foreground action.
  • The explicit action uses the existing target-bound step-up flow and retains the queued record on cancellation, authorization failure, or delivery failure.
  • Confirmed closure removes the record; no operator secret or grant is persisted in outbox/IndexedDB/service-worker state.
  • Behavioral tests prove queue → background skip → explicit authorization → confirmed close, plus focused and full suites are green.

Non-duplication evidence

Historical #341 added fresh authorization and #427 added offline closure independently; neither reconciles these contracts. Current origin/main still sends queued closes without a grant from background delivery.

## Problem Offline **Queue close & next** durably stores an `issue-close` operation, but automatic foreground/background drains submit it without the target-bound fresh authorization required by the close endpoint. In secure operator mode the server returns 428 and the delivery center misclassifies the intent as a generic failed delivery. ## Product slice Keep queued closure intent durable, but classify it as awaiting authorization. Never execute it from background or bulk automatic drains. Offer an explicit **Authorize & close** action that obtains a fresh grant for the exact issue and removes the queued operation only after confirmed closure. ## Acceptance criteria - Background and automatic bulk drains skip queued `issue-close` records without marking them failed. - Delivery Center identifies closures as awaiting authorization and exposes an explicit foreground action. - The explicit action uses the existing target-bound step-up flow and retains the queued record on cancellation, authorization failure, or delivery failure. - Confirmed closure removes the record; no operator secret or grant is persisted in outbox/IndexedDB/service-worker state. - Behavioral tests prove queue → background skip → explicit authorization → confirmed close, plus focused and full suites are green. ## Non-duplication evidence Historical #341 added fresh authorization and #427 added offline closure independently; neither reconciles these contracts. Current `origin/main` still sends queued closes without a grant from background delivery.
timmy self-assigned this 2026-08-10 12:20:01 +00:00
timmy closed this issue 2026-08-10 12:31:00 +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#483
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?