Prevent failed curation tasks from prematurely triggering the de-dupe fan-in step #23
Labels
No labels
agent
blocked
agent
new
agent
review
agent
working
complexity
high
complexity
low
priority
high
priority
low
priority
medium
risk
high
risk
low
risk
medium
type
bug
type
chore
type
feature
type
security
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
tfks/trippin#23
Loading…
Add table
Add a link
Reference in a new issue
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?
runCuratePhoto's finally block calls decrementRunningRuns every time the task runs (handlers.ts:336). If a curate-photo task throws and the worker retries it, the finally decrements the counter again on each retry. Enough retries can drive remaining_count to zero early and fire flag-duplicates before phase 1 is actually done (or fire it more than once). The per-photo data writes are fine on retry; it's the trip-run counter that double-counts. This only affects the trip-wide composite path (/api/trips/:id/curation), not the per-photo or free verbs you're exercising now — but it's a genuine bug worth a ticket.