Daytona API key expiry is unhandled in few of the places

[thesujai]

What happened?

My Daytona configuration was older than 2 weeks in my DB, and the key I was using was expired. When I went to settings/sandbox-providers page I got a internal server error. This was because the ACCESS_DENIED in the get sandbox providers was unhandled, we should handle it.

Also same can be observed while asking a agent to do something in Sandbox if your key is expired, this case is unhandled.

Ideally we should handle it and mark the status of the sadbox provider as failed and give a proper status_reason.

How many more places can this be unhandled?

Steps to reproduce

1. Create a key in daytona with all the necessary permissions in daytona.
2. Configure it in platform - watch everything works
3. Revoke the key from Daytona
4. Create turn and ask to use sandbox, watch the unhandled error(first error)
5. In the DB set the updated_at less than 13 days(for faster repro)
6. Go to settings page in sandbox provider section - see the unhandled error

How are you running TrueForge?

Docker Compose

Version

main

Environment

NA

[thesujai]

First step would be to identify the places where this is unhandled, then think about how we should handle it. Which all place would require the status- failed to updated in DB as well

[Elioooon]

I traced the two reported flows before implementing:

1. GET /settings/sandbox-providers calls checkSnapshotStatus; the Daytona buildImage / getImageBuildStatus 401 or 403 currently escapes and becomes a 500.
2. A new agent sandbox can fail in DaytonaSandboxProvider.createSandbox() after a ready status was served from the 13-day cache.
3. An existing sandbox can fail during exec(); that method currently converts the Daytona exception into ExecResult.success = false, so the server never gets a typed auth error to persist.

The smallest complete fix appears to be:

• centralize the 401/403 -> persisted failed + status_reason mapping in the server package;
• catch it in checkSnapshotStatus; and
• pass a small provider error callback into the Daytona provider so create/exec failures update the same stored status before they are surfaced/converted.

This keeps the database concern out of trueforge-core and avoids a network revalidation on every turn. I am proceeding with this scoped implementation unless you prefer a different boundary.