zeroclaw-labs/zeroclaw · error
statuses request returned {}
Error message
statuses request returned {} What it means
While list_projects enriches data it fetches workflow statuses in a parallel task; a non-2xx on that request bails with the bare status (no body inlined). Usually 401/403 - credentials or permission for the statuses endpoint - or 404 when the deployment or API version no longer serves that endpoint path. Because it runs inside the JoinSet, this failure fails the whole list_projects call.
Source
Thrown at crates/zeroclaw-tools/src/jira_tool.rs:545
Some(e) => req.basic_auth(e, Some(&token)),
None => req.bearer_auth(&token),
};
let resp = req.send().await.map_err(|e| {
::zeroclaw_log::record!(
ERROR,
::zeroclaw_log::Event::new(
module_path!(),
::zeroclaw_log::Action::Fail
)
.with_outcome(::zeroclaw_log::EventOutcome::Failure)
.with_attrs(::serde_json::json!({"error": format!("{}", e)})),
"jira: statuses request failed"
);
anyhow::Error::msg(format!("statuses request failed: {e}"))
})?;
if !resp.status().is_success() {
anyhow::bail!("statuses request returned {}", resp.status());
}
resp.json::<Value>().await.map_err(|e| {
::zeroclaw_log::record!(
ERROR,
::zeroclaw_log::Event::new(
module_path!(),
::zeroclaw_log::Action::Fail
)
.with_outcome(::zeroclaw_log::EventOutcome::Failure)
.with_attrs(::serde_json::json!({"error": format!("{}", e)})),
"jira: failed to parse statuses response"
);
anyhow::Error::msg(format!("failed to parse statuses response: {e}"))
})
}
.await;
(i, result)View on GitHub (pinned to 88bb9c8533)
Solutions
- Map the numeric status: 401 -> token expired or revoked, refresh it; 403 -> grant workflow/status read permission; 404 -> endpoint missing for that Jira version, upgrade zeroclaw-tools
- Reproduce with curl against the statuses endpoint named in the error context
- Re-run list_projects after the fix - the failure is per-request, not data corruption
- If it persists, compare the exact URL being polled (enable reqwest/zeroclaw log output) against your Jira version's REST reference
Defensive patterns
Strategy: try-catch
Type guard
fn is_jira_statuses_http_failure(err: &anyhow::Error) -> bool {
err.to_string().starts_with("statuses request returned ")
} Try / catch
match jira.execute(list_projects_args).await {
Ok(res) => res,
Err(e) if is_jira_statuses_http_failure(&e) => {
let code = e.to_string()
.rsplit(' ')
.next()
.and_then(|s| s.trim_matches('.').parse::<u16>().ok());
match code {
Some(401) => refresh_credentials(),
Some(403) => report_permission_gap(&e),
_ => return Err(e),
}
}
Err(e) => return Err(e),
} Prevention
- Keep session lifetimes shorter than token lifetimes
- Re-verify the Jira version's REST surface after upgrades
- Give integration users read access to workflow statuses
- Monitor this message - it is the earliest sign of endpoint drift
When it happens
Trigger: list_projects where the statuses endpoint is blocked for the token user, or the Jira version serves it under a different REST path - older Server builds and Cloud revisions have shuffled workflow-status endpoints; also a token revoked mid-session between the project call and the statuses call.
Common situations: Jira upgrades renaming status endpoints; integration users without workflow read permission; long-lived agent sessions outliving their tokens.
Related errors
- Jira get_ticket failed ({status}): {}
- Jira search_tickets failed ({status}): {}
- Jira comment_ticket failed ({status}): {}
- Jira list_projects failed ({status}): {}
- Jira list_projects users failed ({status}): {}
AI-assisted analysis of zeroclaw-labs/zeroclaw@88bb9c8533 (2026-08-23).
Data as JSON: /api/errors/b64b320d7f266dd8.
Report an issue: GitHub.