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

Keep Today progress photo retries bound to the intended evidence #1056

New Issue
Closed
opened 2026-08-18 02:19:39 +00:00 by rockachopa · 0 comments
rockachopa commented 2026-08-18 02:19:39 +00:00
Member
Copy Link

Problem

Today progress drafts preserve the comment operation ID when only the text is unchanged. Photo replacement, removal, reordering, caption edits, or attachment operation changes can therefore reuse an ID for a different payload. The authored outbox currently returns the already queued item for any repeated operation ID without checking the payload. If durable admission succeeds and photo-draft cleanup then fails, a retry can appear to accept edited evidence while retaining the older queued photo.

User impact

A mobile operator replacing or redacting evidence can unknowingly queue the previous image. Cleanup failures also present admitted work as though delivery still needs retrying.

Acceptance criteria

  • The Today progress operation identity is preserved only when body and ordered attachment identity/caption metadata are unchanged.
  • Adding, replacing, removing, reordering, or recaptioning evidence rotates the operation ID before admission.
  • Reusing an authored-outbox operation ID with a different target, body, or attachment payload fails closed; an identical replay remains idempotent.
  • After durable admission, cleanup failure is checkpointed as cleanup-pending and retrying cleanup does not re-admit delivery.
  • Focused behavioral tests cover payload changes and cleanup recovery; the full suite and release checks pass.

Implementation should use strict TDD and preserve the active Today session/item.

## Problem Today progress drafts preserve the comment operation ID when only the text is unchanged. Photo replacement, removal, reordering, caption edits, or attachment operation changes can therefore reuse an ID for a different payload. The authored outbox currently returns the already queued item for any repeated operation ID without checking the payload. If durable admission succeeds and photo-draft cleanup then fails, a retry can appear to accept edited evidence while retaining the older queued photo. ## User impact A mobile operator replacing or redacting evidence can unknowingly queue the previous image. Cleanup failures also present admitted work as though delivery still needs retrying. ## Acceptance criteria - The Today progress operation identity is preserved only when body and ordered attachment identity/caption metadata are unchanged. - Adding, replacing, removing, reordering, or recaptioning evidence rotates the operation ID before admission. - Reusing an authored-outbox operation ID with a different target, body, or attachment payload fails closed; an identical replay remains idempotent. - After durable admission, cleanup failure is checkpointed as cleanup-pending and retrying cleanup does not re-admit delivery. - Focused behavioral tests cover payload changes and cleanup recovery; the full suite and release checks pass. Implementation should use strict TDD and preserve the active Today session/item.
timmy was assigned by rockachopa 2026-08-18 02:19:39 +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#1056
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?