mirror of
https://github.com/fabro-sh/fabro.git
synced 2026-08-28 05:27:41 +00:00
d2510447fe
A Daytona-backed run could fail five seconds after start when the sandbox git clone hit a transient GitHub "Repository not found" error. Clone-based providers mint an installation access token and clone with it in the same breath, but GitHub replicates a new token to its edge cache sites asynchronously. A clone that starts within a second of the mint can be rejected before the token is visible to the site serving it, and on a private repo that rejection arrives as "Repository not found" because GitHub answers unauthorized reads with 404. Nothing retried the clone, and the failure classified as `deterministic`, which is the one category `loop_restart` refuses to restart. An identical run relaunched 46 seconds later succeeded with no changes. A successful mint is what makes the message safe to retry. `resolve_clone_credentials` already fails loudly on every deterministic explanation for a clone 404: the installation lookup 404s when the App is not installed for the owner, and token creation 422s when the installation does not cover the repo. Once credentials are in hand, "not found" from the clone itself cannot mean "no access". Add `clone_retry` and use it from both clone-based providers: 3 attempts with 3s then 9s backoff, reusing the same token so replication keeps making progress instead of restarting the clock. Token-replication signatures retry only when credentials are present, so a public clone of a wrong URL still fails fast. Infrastructure failures retry either way. The Docker provider had the identical single-shot clone and is the default runtime provider, so it is covered too. Also fix two nearby issues found while reading the area: - The GitHub-URL-parse path in the Daytona clone skipped `fail_init`, unlike every sibling path, so `InitializeFailed` was never emitted. - The `classify_exec_failure` hint for "repository not found" asserted the App installation may not cover the repo. After a successful scoped mint that diagnosis is impossible, and it sent operators hunting a configuration problem that did not exist. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| apps | ||
| components | ||
| foundation | ||
| packages/fabro-api-client | ||