Review 1.3: a request that fails in an unexpected way is completed as failed, not left Running
HandleAsync only turned a few exception types into the request's error; anything else (a lock or command timeout, a JSON or argument error) escaped, leaving the row Running and the page waiting until housekeeping failed it minutes later. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
a6a72661e7
commit
12cf5a1e94
1 changed files with 3 additions and 1 deletions
|
|
@ -104,7 +104,9 @@ public sealed partial class AgentRequestService(
|
||||||
{
|
{
|
||||||
error = $"Agenten fik ikke svar inden for {RequestTimeout.TotalMinutes:0} minutter.";
|
error = $"Agenten fik ikke svar inden for {RequestTimeout.TotalMinutes:0} minutter.";
|
||||||
}
|
}
|
||||||
catch (Exception ex) when (ex is CredentialException or KeyNotFoundException or InvalidOperationException or DiscoveryFailedException or DbException)
|
// Anything else (a lock timeout, a repository error while storing a discovery …) is the request's result too, so it
|
||||||
|
// is never left as Running for the web UI to wait on.
|
||||||
|
catch (Exception ex) when (ex is not OperationCanceledException)
|
||||||
{
|
{
|
||||||
error = ex.Message;
|
error = ex.Message;
|
||||||
}
|
}
|
||||||
|
|
|
||||||
Loading…
Add table
Reference in a new issue