different-ai/openwork · error · DiagnosticFailure
http_${status}
http_${status}
Error message
The diagnostic request returned unexpected HTTP ${status}. What it means
sendRequest in egress-diagnostics.ts records the HTTP status and checks it against input.expectedStatuses; if the status is unexpected, httpFailure produces a DiagnosticFailure with code http_${status} and a message embedding that status. This means the connection succeeded but the Diagnostics endpoint (or an intermediary) answered with an HTTP status the diagnostic flow did not anticipate.
Source
Thrown at ee/apps/den-api/src/egress-diagnostics.ts:292
runId: string
step: string
timeoutMs: number
url: string
}): Promise<Response> {
let response: Response
try {
response = await input.fetchImpl(input.url, {
...input.init,
headers: requestHeaders(input.runId, input.step, input.init?.headers),
signal: input.init?.signal ?? AbortSignal.timeout(input.timeoutMs),
})
} catch (error) {
throw networkFailure(error)
}
input.evidence.httpStatuses.push(response.status)
const diagnosticId = response.headers.get(EGRESS_DIAGNOSTIC_ID_HEADER) ?? ""
if (diagnosticIdPattern.test(diagnosticId)) input.evidence.diagnosticIds.push(diagnosticId)
if (!input.expectedStatuses.includes(response.status)) throw httpFailure(response.status, input.category)
if (!diagnosticIdPattern.test(diagnosticId)) {
throw new DiagnosticFailure({
action: "Ask the network administrator to inspect whether a proxy, gateway, or service mesh replaced the response or removed x-openwork-diagnostic-id.",
category: input.category,
code: "diagnostic_reference_missing",
message: "A response arrived, but it did not contain proof that it came from the Diagnostics application.",
owner: "network-administrator",
})
}
return response
}
function protocolFailure(category: EgressDiagnosticCategory, code: string, message: string): DiagnosticFailure {
return new DiagnosticFailure({
action: "Give OpenWork support the run ID and diagnostic reference so the response contract can be compared with the remote trace.",
category,
code,
message,View on GitHub (pinned to 2b7df46e8a)
Solutions
- For http_401/403: verify Den and the Diagnostics deployment share the same synthetic diagnostic token and that the proxy forwards Authorization headers.
- For http_407: configure proxy credentials for the Den runtime and confirm Node outbound requests use the approved proxy path.
- For 404/502/5xx: check the Diagnostics deployment health, its ingress/routing, and that the diagnostic URL matches the deployed service.
- Compare the recorded status in evidence.httpStatuses with expectedStatuses to identify what answered.
Defensive patterns
Strategy: try-catch
Validate before calling
// verify token parity before sending
if (denDiagnosticToken !== diagnosticsDeploymentToken) {
throw new Error('synthetic diagnostic token mismatch between Den and Diagnostics')
} Type guard
function isHttpDiagnosticFailure(e: unknown): e is { code: `http_${number}`; status: number } {
return typeof e === 'object' && e !== null && /^http_\d+$/.test(String((e as { code?: string }).code ?? ''))
} Try / catch
try {
result = await sendRequest(input)
} catch (error) {
if (isHttpDiagnosticFailure(error)) {
if (error.status === 401 || error.status === 403) checkSyntheticToken()
else if (error.status === 407) configureProxyCredentials()
else checkDiagnosticsDeploymentHealth()
} else throw error
} Prevention
- Deploy Den and Diagnostics with the same synthetic diagnostic token.
- Ensure proxies forward the Authorization header untouched.
- Pre-authenticate the Den runtime with the corporate proxy (avoid 407).
- Monitor Diagnostics deployment health and ingress routing.
When it happens
Trigger: An egress diagnostic request where the response status is not in expectedStatuses — e.g. Diagnostics answers 401/403 because the synthetic token mismatches, 407 from an authenticating proxy, 404/502 from a wrong or broken endpoint, or 5xx from a crashed Diagnostics deployment.
Common situations: Den and Diagnostics deployed with different synthetic diagnostic tokens; a corporate proxy stripping the Authorization header or demanding proxy auth (407); ingress routing the diagnostic path to the wrong service; Diagnostics pod crashing under load.
Related errors
- Could not load egress diagnostics (${response.status}).
- Egress diagnostic could not start (${response.status}).
- Could not save the diagnostic token (${response.status}).
- The Den container could not complete the outbound connection
- Failed to fetch latest-mac.yml (${response.status} ${respons
AI-assisted analysis of different-ai/openwork@2b7df46e8a (2026-09-01).
Data as JSON: /api/errors/9dc370b80947c315.
Report an issue: GitHub.