Conversation
Signed-off-by: Reg Cheramy <rcheramy@gmail.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 32fbaad35b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } | ||
| if (task.attempts >= maxAttempts) { | ||
| logger.e { "Task with id $id has reached max attempts ($maxAttempts), marking as failed" } | ||
| repository.updateStatus(id, TaskStatus.Failed) | ||
| return@flow | ||
| } | ||
| repository.incrementAttempts(id) |
There was a problem hiding this comment.
When a recording stays offline beyond three attempts, its entry remains transcription_error, so the existing feed/details UI still offers Retry; retryRecording/retryLocalRecording then inserts another task for the same recording entry without cancelling the original. With this cap removed, both tasks remain pending and, after connectivity returns, each can transcribe and run the agent/tool path because the scheduler checks only the task status, potentially creating duplicate notes, reminders, or other actions. Reuse or cancel the existing pending task, or suppress manual retry while it is queued.
Useful? React with 👍 / 👎.
1 participant
Summary
Keep recoverable Index recording-processing tasks pending until they succeed instead of permanently failing them after three attempts.
Problem
I captured many Index 01 recordings while fishing in the Northwest Territories without internet access. The audio was preserved, but after the queue exhausted its three attempts, every recording had to be opened and retried manually after connectivity returned. That also prevented transcript-bearing webhooks from running automatically.
RecoverableTaskExceptionalready distinguishes transient network/model-busy failures from deterministic failures. Deterministic failures are immediately markedFailed, so the generic three-attempt cap only cuts off tasks explicitly classified as recoverable.Change
PersistentQueueScheduler.Pendingso scheduled retries and app-start recovery can continue.Once transcription succeeds, the existing
onTranscriptionPersistedpath delivers configured transcript-bearing webhooks.Testing
git diff --checklocalAudioProcessing_transcriptionNetworkError_keepsRetryingUntilServiceReturns.AI disclosure
AI assistance was used to inspect the processing pipeline, identify the retry cutoff, implement the minimal patch, and draft this PR. I reviewed the resulting change and test.