Kuberwastaken/claurst · error
Payload too large (413)
Error message
Payload too large (413)
What it means
The team-memory batch PUT exceeded the server's request-size limit: HTTP 413 Payload Too Large. The batch of entries sent in one request is bigger than the endpoint accepts, so nothing in the batch was stored.
Solutions
- Split the batch into smaller chunks and upload sequentially
- Reduce individual entry sizes (large memories should be summarized or split)
- After splitting, re-pull first if an ETag conflict arises
Defensive patterns
Strategy: retry
When it happens
Trigger: Thrown at src-rust/crates/core/src/team_memory_sync.rs:337 when the library encounters an invalid state.
Common situations: See trigger scenarios.
AI-assisted analysis of Kuberwastaken/claurst@b0637c97ec (2026-09-10).
Data as JSON: /api/errors/0f417be59d2b331c.
Report an issue: GitHub.
Appendix: source
Thrown at src-rust/crates/core/src/team_memory_sync.rs:337
match status {
200 | 201 | 204 => {
if let Some(etag) = response
.headers()
.get("etag")
.and_then(|v| v.to_str().ok())
{
state.last_known_etag = Some(etag.to_string());
}
// Update local checksum map to reflect uploaded state
for entry in &batch {
state
.server_checksums
.insert(entry.key.clone(), entry.checksum.clone());
}
Ok(())
}
412 => anyhow::bail!("Conflict (412 Precondition Failed): ETag mismatch, retry needed"),
413 => anyhow::bail!("Payload too large (413)"),
401 | 403 => anyhow::bail!("Authentication error ({})", status),
_ => anyhow::bail!("Upload failed with status {}", status),
}
}
/// Recursively scan `team_dir` for `.md` files, returning entries sorted by key.
async fn scan_local_files(&self) -> Result<Vec<TeamMemoryEntry>> {
let mut entries = Vec::new();
if !self.team_dir.exists() {
return Ok(entries);
}
// Iterative DFS using an explicit stack to avoid deep recursion
let mut stack = vec![self.team_dir.clone()];
while let Some(dir) = stack.pop() {
let mut read_dir = tokio::fs::read_dir(&dir)View on GitHub (pinned to b0637c97ec)