fix(queue): clear in_progress row on retry to prevent duplicate UI entries#226
Merged
Conversation
…tries Each retry called ReaddJob which generated a new goqite message ID, but the in_progress_items row keyed by the previous ID was never deleted. The same path then appeared in multiple tables simultaneously (pending goqite + 1-N stale in_progress rows), surfacing in the UI as up to 3 duplicate entries matching maxRetries=3. Add Queue.ClearInProgress and call it before ReaddJob on both the retry and MarkAsError-fallback paths. Also include errorType in the failure log so the underlying upload error is easier to diagnose.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Queue.ClearInProgress(ctx, msgID)and call it fromhandleProcessingErrorbeforeReaddJobon both the retry path and theMarkAsError-fallback path.errorTypealongside the error message inhandleProcessingErrorso the underlying upload failure (e.g. nntppool validation errors after the v4.11.1 bump) is easier to identify from user logs.internal/queue/queue_test.gocovering the retry cycle andIsPathInQueuevisibility, both green under-race.Root cause
Each retry calls
ReaddJob, which sends a new goqite message with a fresh ID. The previousin_progress_itemsrow (keyed by the old message ID) was never deleted, so the same path showed up in multiple tables at once: the new pending goqite row plus 1–3 stalein_progress_itemsrows. The cap at 3 matchedmaxRetries = 3ininternal/processor/processor.go.Test plan
go test -race ./internal/queue/ ./internal/processor/passesgo vet ./internal/queue/ ./internal/processor/cleanpending → in_progress → pending → … → erroredinstead of multiple duplicate rows