kyleandClaude Opus 5.5
67ddda514b
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
32 lines
1.4 KiB
Markdown
32 lines
1.4 KiB
Markdown
## honcho-send-refused
|
|
|
|
**What you see.** `memoryd` logs one line for a turn that Honcho refused, or that could not be
|
|
sent at all, then this entry:
|
|
|
|
```text
|
|
memoryd: turn 3 of session mm-chat-1 was not sent: Honcho refused the request (status, HTTP 422); it is marked failed; see docs/runbook.md#honcho-send-refused
|
|
```
|
|
|
|
or `memoryd: turn 3 of session mm-chat-1 cannot be sent (too-long); it is marked failed; …` for a
|
|
turn whose text needs more than 100 messages of 25,000 characters.
|
|
|
|
**Why.** Honcho answered with a 4xx other than 401 or 403, a redirect, or a body `roncho` could
|
|
not read; sending the same again would get the same answer, or could store it twice. So the turn
|
|
is marked `failed` in `memory/honcho.jsonl`, with the kind and the status, and the next turn goes
|
|
on. The line never holds the turn's text or Honcho's answer (a 422 echoes the whole request).
|
|
|
|
**Confirm.**
|
|
|
|
```sh
|
|
grep -n '"type":"failed"' "$BOXMAKER_HOME/memory/honcho.jsonl"
|
|
```
|
|
|
|
A 422 usually means a name Honcho does not accept, or text over its limit; a 404, a workspace or
|
|
session removed on the Honcho side.
|
|
|
|
**Fix.** A failed turn is not sent again by itself. To send it again after fixing the cause,
|
|
stop `memoryd`, keep a copy of the ledger, remove the turn's `failed` line (see
|
|
`honcho-ledger-damaged` for what removing a line means), and start `memoryd`.
|
|
|
|
**Check.** The next turns are sent (`sent` lines follow).
|