nikivdev/code · error
{error}
Error message
{error} What it means
This error is raised by `maple_call_tool` when the JSON-RPC call itself succeeded (no envelope-level error) but the tool's *result* payload embeds a domain-level error, detected by `maple_tool_result_error`. The library re-bails with that inner error string verbatim (`{error}`), so the message text comes from the Maple tool, not from this crate. It marks the difference between transport/protocol failures and tool-execution failures.
Source
Thrown at src/codex_telemetry.rs:464
.filter(|value| !value.is_empty())
.or_else(|| Some("Maple tool returned an unspecified error".to_string()))
}
fn maple_call_tool(
config: &MapleReadConfig,
name: &str,
arguments: serde_json::Value,
) -> Result<serde_json::Value> {
let result = maple_json_rpc_request(
config,
"tools/call",
serde_json::json!({
"name": name,
"arguments": arguments,
}),
)?;
if let Some(error) = maple_tool_result_error(&result) {
anyhow::bail!("{error}");
}
Ok(result)
}
pub fn status() -> Result<CodexTelemetryStatus> {
let config = parse_maple_exporter_config_from_env()?;
let state = load_state()?;
let state_path = telemetry_state_path()?;
let events_path = codex_skill_eval::events_log_path()?;
let outcomes_path = codex_skill_eval::outcomes_log_path()?;
Ok(CodexTelemetryStatus {
enabled: config.is_some(),
configured_targets: config
.as_ref()
.map(|value| value.targets.len())
.unwrap_or(0),
service_name: configView on GitHub (pinned to a747e741ae)
Solutions
- Act on the inner message: if the trace is not found, flush first (`inspect_trace` with flush_first=true) and re-check the trace_id.
- Verify the MAPLE_API_TOKEN has access to the requested trace/workspace.
- Retry the tool call if the message indicates a transient internal error.
- Check Maple server logs for the tool-side failure if the message is opaque.
Example fix
// before: inspecting a stale trace id
inspect_trace("abc123", false)?;
// after: flush pending telemetry first so the trace exists server-side
inspect_trace("abc123", true)?; Defensive patterns
Strategy: try-catch
Validate before calling
// ensure a trace id exists before inspecting it
let known = list_recent_trace_ids()?;
if !known.contains(&trace_id.to_string()) {
eprintln!("trace {trace_id} unknown; flushing telemetry first");
flush(64);
} Type guard
fn tool_result_ok(result: &serde_json::Value) -> bool {
maple_tool_result_error(result).is_none()
} Try / catch
match maple_call_tool("inspect_trace", args) {
Err(e) if !e.to_string().contains("Maple MCP") => {
// tool-level (domain) error: inspect the message for 'not found' / 'denied'
eprintln!("Maple tool failed: {e}");
}
Err(e) => return Err(e),
Ok(r) => r,
} Prevention
- Always flush pending telemetry before querying a fresh trace id
- Check token permissions for the target workspace/trace
- Retry tool calls on transient internal errors with backoff
- Keep the inner error text in logs — it comes from the Maple tool and is diagnostic
When it happens
Trigger: `maple_call_tool` (called by `inspect_trace`) obtains a result envelope where `maple_tool_result_error(&result)` returns `Some`, e.g. the tool reports 'trace not found', permission denied for the trace, or an internal tool failure, and the function bails with that string.
Common situations: Querying a trace_id that has been flushed/expired on the server, requesting a trace owned by another API token (RBAC denial), or the Maple tool hitting an internal error while aggregating telemetry.
Related errors
- Maple MCP request failed ({}): {}
- Maple MCP error {code}: {message}
- Gemini API error {}: {}
- FLOW_CODEX_MAPLE_LOCAL_ENDPOINT and FLOW_CODEX_MAPLE_LOCAL_I
- FLOW_CODEX_MAPLE_HOSTED_ENDPOINT and FLOW_CODEX_MAPLE_HOSTED
AI-assisted analysis of nikivdev/code@a747e741ae (2026-09-01).
Data as JSON: /api/errors/833bf95a512ed663.
Report an issue: GitHub.