JuliusBrussee/caveman · error · Error
cave_eve_terminal_${result.status}
cave_eve_terminal_${result.status}
Error message
cave_eve_terminal_${result.status} What it means
The Eve adapter awaits `session.send({ message }).result()` and requires `status === "completed"`; the binding allows `"completed" | "failed" | "waiting"`. Any non-completed status is interpolated into the code — in practice `cave_eve_terminal_failed` or `cave_eve_terminal_waiting` — and throws before any identity or usage evidence is read from the events. The interpolated suffix is the actual Eve session outcome and is the starting point for diagnosis.
Solutions
- Parse the status out of the message with `/cave_eve_terminal_([a-z]+)$/` and branch on it
- For `waiting`: poll or resume the existing session instead of starting a new one
- For `failed`: inspect the Eve server logs / session events for the root cause, fix it, then retry with a fresh session
- Add a client-side session deadline so sessions cannot dangle indefinitely in waiting
Defensive patterns
Strategy: try-catch
Validate before calling
null
Try / catch
try {
return await adapter.run(req);
} catch (e) {
const m = /cave_eve_terminal_([a-z]+)$/.exec((e as Error).message);
if (m?.[1] === 'waiting') return pollSessionUntilSettled(session);
if (m?.[1] === 'failed' && attempt < 2) return runOnce(req, attempt + 1);
throw e;
} Prevention
- Set a client-side session deadline so sessions never dangle in 'waiting'
- Monitor Eve server health; most 'failed' statuses have a server-side log entry
- Branch on the interpolated status — 'waiting' needs polling, 'failed' needs diagnosis, not blind retries
When it happens
Trigger: Eve runtime error mid-run → `cave_eve_terminal_failed`; session paused awaiting external input/approval → `cave_eve_terminal_waiting`; cancellation propagated by the Eve server as a failed status.
Common situations: Eve server-side incidents or resource exhaustion; prompts exceeding server limits; sessions left dangling in `waiting` because a required event or approval never arrives.
Related errors
- cave_eve_usage_missing
- cave_eve_runtime_identity_missing
- cave_harness_incomplete_evidence
- cave_harness_upstream_version_mismatch
- cave_mastra_terminal_failure
AI-assisted analysis of JuliusBrussee/caveman@766dce6b13 (2026-08-18).
Data as JSON: /api/errors/a8e8153ebf979bc7.
Report an issue: GitHub.
Appendix: source
Thrown at packages/agent/src/adapters.ts:257
export function createEveAdapter(
identity: HarnessAdapterIdentity,
session: EveSessionBinding,
): HarnessAdapter {
assertSupportedUpstream(identity, EVE_VERSION, "eve", "eve");
return createHarnessAdapter("eve", identity, {
package: "eve/client",
class: "ClientSession",
method: "send.result",
usage: "step.completed.data.usage",
}, async (request) => {
const startedAt = performance.now();
const response = await session.send({
message: request.prompt,
...(request.signal === undefined ? {} : { signal: request.signal }),
});
const result = await response.result();
if (result.status !== "completed") throw new Error(`cave_eve_terminal_${result.status}`);
const identity = eveRuntimeIdentity(result.events);
if (identity.upstreamVersion !== request.build.harness.upstream_version) {
throw new Error("cave_harness_upstream_version_mismatch");
}
const usage = usageFromEveEvents(result.events, request.plan.reasoning !== "none");
return harnessExecution({
request,
text: result.message ?? "",
provider: identity.provider,
model: identity.model,
usage,
latencyMs: Math.round(performance.now() - startedAt),
});
});
}
export interface MastraAgentBinding {
generate(messages: string, options?: {View on GitHub (pinned to 766dce6b13)