elastic / elastic/docs-builder
Codex: Differentiate 404/permission failures from genuine errors in clone
- Dominant language
- C#
- Stars
- 24
- Forks
- 44
- Avg merge
- 1d 7h
- Merged PRs (30d)
- 146
Description
## Background
The `CloneRepository` catch block in `CodexCloneService` downgrades **all** exceptions to warnings:
```csharp
// Emit warning instead of error: repos may be in the link index before the clone
// workflow has permission to access them. Continue with repos we can clone.
context.Collector.EmitWarning(..., $"Could not clone repository '{repoName}': {ex.Message}");
```
This is intentional for the "repo in the link index we don't have permission to yet" case (404/private), but it also silently swallows genuine errors: bad git references in config, network failures on repos we *do* have access to, disk errors, etc.
## Problem
There's currently no way to distinguish these cases because `ExecIn` uses `Proc.Exec`, which streams git's stderr directly to the console and throws `ProcExecException` with only the exit code + command in the message — not git's actual output (e.g. `"fatal: repository not found"`).
## What's needed
Add a capturing variant to `ExternalCommandExecutor` — something like `ExecCapturing(...)` that uses `Proc.Start` with a writer that records stderr — so `CodexGitRepository.Fetch` can return enough context to let `CloneRepository` distinguish:
- **"repository not found" / auth failure (HTTP 404)** → warning, skip (current behaviour, keep)
- **Any other failure** → error, fail the build (currently silently warned)
## Related
PR #3460 fixed `codex index` resilience. This issue tracks making `codex clone` equally precise about which failures it tolerates.
Contributor guide
Assessment
This issue has not been assessed yet.