Suppress cancel-error dialog in auto-translate#11113
Merged
Merged
Conversation
When the user presses Cancel during translation, the HttpClient call throws OperationCanceledException (or TaskCanceledException) which the generic catch in DoTranslate surfaced as a translation-error dialog with a stack trace. Cancel should be silent — the finally block already sets StatusText to "Translation cancelled". Add a guarded catch for user-initiated cancellation; genuine cancellation-shaped errors still fall through to the existing handler. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adjusts the auto-translate workflow so that user-initiated cancellation (Cancel button) no longer surfaces as a translation error dialog when the underlying translator throws OperationCanceledException / TaskCanceledException.
Changes:
- Add a guarded
catch (OperationCanceledException) when (_abort)to suppress the error dialog on user cancellation. - Rely on the existing
finallyblock to report “Translation cancelled” and restore UI state.
| } | ||
|
|
||
| } | ||
| catch (OperationCanceledException) when (_abort) |
Cancel() called _cancellationTokenSource.Cancel() before setting _abort = true, so the worker thread could observe cancellation and throw OperationCanceledException before _abort was set (and even when ordering is right, the non-volatile bool write isn't guaranteed visible across threads). - Set _abort before cancelling the token, so intent is recorded first. - Widen the catch guard to also check the CTS's IsCancellationRequested, which is internally synchronized and race-free. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Ari4ka
approved these changes
May 23, 2026
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
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
When the user pressed Cancel during auto-translate (reported with llama.cpp, but applies to every engine that honors the cancellation token), the
HttpClientcall inside the translator threwOperationCanceledException/TaskCanceledException. The catch-all inAutoTranslateViewModel.DoTranslatesurfaced this as aTranslationErrorWindowwith a stack trace, even though the user just clicked Cancel.Add a guarded catch for user-initiated cancellation:
```csharp
catch (OperationCanceledException) when (_abort)
{
// User pressed Cancel — let the finally block report it; do not surface as an error.
}
```
TaskCanceledExceptionderives fromOperationCanceledException, so this covers both shapes.finallyblock still setsStatusText = TranslationCancelledand re-enables the UI.when (_abort)guard means a stray non-user cancellation (e.g. an internal client timeout that we didn't initiate) still hits the regular error dialog, so genuine failures aren't masked.Test plan
🤖 Generated with Claude Code