elastic / elastic/docs-builder

Codex: Differentiate 404/permission failures from genuine errors in clone

Open
#3,461 2 comments 0 reactions 0 assignees View on GitHub
ai-triaged ai:eng-question enhancement needs triage stale
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.