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

Bind offline mutation queues to their originating Gitea account #238

New Issue
Closed
opened 2026-08-07 22:49:05 +00:00 by rockachopa · 0 comments
rockachopa commented 2026-08-07 22:49:05 +00:00
Member
Copy Link

Problem

Offline issue and authored-message queues persist mutation intent without the Gitea login that created it. On startup/reconnect they can flush through a newly configured token owner, silently attributing an old browser queue to the wrong account. Legacy unowned records are equally unsafe.

Vertical slice

Bind every queued mutation to the last freshly confirmed Gitea login. Flush only for the matching live identity. Quarantine legacy or mismatched entries in Drafts so users can copy or discard them without transmitting.

Acceptance criteria

  • New issue/message queue entries record the confirmed owner login.
  • Matching-account reconnect preserves existing automatic sequential/idempotent flush behavior.
  • Unknown, stale, fallback, malformed, or mismatched identity performs no queued mutation.
  • Legacy unowned queue records are preserved but never auto-sent.
  • Drafts clearly identifies quarantined ownership and offers copy/discard, not retry/send.
  • Behavioral tests cover matching, mismatch, unavailable identity, legacy migration, and regressions.
  • Updated service-worker cache ships the new client modules.

Evidence / non-duplication

Current origin/main has identity protection only for the read-only offline My Work snapshot. Issues #232/#233 and #234/#235 introduced the two write outboxes, but neither schema records an owner or gates flush on identity. Historical title scan found no account-bound outbox work.

## Problem Offline issue and authored-message queues persist mutation intent without the Gitea login that created it. On startup/reconnect they can flush through a newly configured token owner, silently attributing an old browser queue to the wrong account. Legacy unowned records are equally unsafe. ## Vertical slice Bind every queued mutation to the last freshly confirmed Gitea login. Flush only for the matching live identity. Quarantine legacy or mismatched entries in Drafts so users can copy or discard them without transmitting. ## Acceptance criteria - New issue/message queue entries record the confirmed owner login. - Matching-account reconnect preserves existing automatic sequential/idempotent flush behavior. - Unknown, stale, fallback, malformed, or mismatched identity performs no queued mutation. - Legacy unowned queue records are preserved but never auto-sent. - Drafts clearly identifies quarantined ownership and offers copy/discard, not retry/send. - Behavioral tests cover matching, mismatch, unavailable identity, legacy migration, and regressions. - Updated service-worker cache ships the new client modules. ## Evidence / non-duplication Current `origin/main` has identity protection only for the read-only offline My Work snapshot. Issues #232/#233 and #234/#235 introduced the two write outboxes, but neither schema records an owner or gates flush on identity. Historical title scan found no account-bound outbox work.
timmy was assigned by rockachopa 2026-08-07 22:49:05 +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#238
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?