hermes-agent

mirror of https://github.com/NousResearch/hermes-agent.git synced 2026-07-29 18:46:59 +00:00

History

0xprincess 309f06b044 fix: prevent session poisoning from empty partial-stream-stub assistant turns A mid-tool-call stream drop with no delivered text produces a partial-stream stub carrying content:'' and tool_calls=None. The conversation loop's truncation path appended it to history as {"role":"assistant","content":""} before the continuation nudge, and strict providers (Moonshot/Kimi via OpenRouter) reject empty assistant content with HTTP 400 ("the message at position N with role 'assistant' must not be empty") on the next replay. Because the message is persisted, every subsequent turn re-failed — the session was unrecoverable. Three layers, smallest blast radius first: 1. conversation_loop (length path): an EMPTY partial-stream stub is no longer appended as an interim assistant message; only the continuation user-message is. Stubs that delivered partial text are still persisted so continuation stitching is unchanged. 2. chat_completion_helpers.build_assistant_message: never serialize a textless assistant turn with content:'' — pad to a single space, the same trick as the reasoning_content pad (#15250, #17400). Tool-call turns are exempt (content:'' alongside tool_calls is accepted everywhere). 3. conversation_loop send boundary: pad a textless assistant turn's empty content to a single space AFTER all content-mutating passes (surrogate sanitize, whitespace normalization, thinking-only drops), before token estimation. This is the durable repair for sessions ALREADY poisoned by older builds: the persisted stub rows are rebuilt to '' on every reload (_rows_to_conversation strips whitespace, so a DB-side pad can't survive) and only a send-time pad repairs them. Verified: 485 tests pass across the four affected files; live replay of a real poisoned session's resumed history against Moonshot via OpenRouter returns HTTP 200 (was HTTP 400).	2026-07-27 19:23:34 -07:00
..
emails	fix: prevent session poisoning from empty partial-stream-stub assistant turns	2026-07-27 19:23:34 -07:00
README.md	fix(ci): make tests, workflows, and attribution reliable under load (#66373 )	2026-07-17 20:55:24 +00:00

0xprincess 309f06b044 fix: prevent session poisoning from empty partial-stream-stub assistant turns

A mid-tool-call stream drop with no delivered text produces a
partial-stream stub carrying content:'' and tool_calls=None.  The
conversation loop's truncation path appended it to history as
{"role":"assistant","content":""} before the continuation nudge, and
strict providers (Moonshot/Kimi via OpenRouter) reject empty assistant
content with HTTP 400 ("the message at position N with role 'assistant'
must not be empty") on the next replay.  Because the message is
persisted, every subsequent turn re-failed — the session was
unrecoverable.

Three layers, smallest blast radius first:

1. conversation_loop (length path): an EMPTY partial-stream stub is no
   longer appended as an interim assistant message; only the
   continuation user-message is.  Stubs that delivered partial text are
   still persisted so continuation stitching is unchanged.

2. chat_completion_helpers.build_assistant_message: never serialize a
   textless assistant turn with content:'' — pad to a single space, the
   same trick as the reasoning_content pad (#15250, #17400).  Tool-call
   turns are exempt (content:'' alongside tool_calls is accepted
   everywhere).

3. conversation_loop send boundary: pad a textless assistant turn's
   empty content to a single space AFTER all content-mutating passes
   (surrogate sanitize, whitespace normalization, thinking-only drops),
   before token estimation.  This is the durable repair for sessions
   ALREADY poisoned by older builds: the persisted stub rows are rebuilt
   to '' on every reload (_rows_to_conversation strips whitespace, so a
   DB-side pad can't survive) and only a send-time pad repairs them.

Verified: 485 tests pass across the four affected files; live replay of
a real poisoned session's resumed history against Moonshot via
OpenRouter returns HTTP 200 (was HTTP 400).

2026-07-27 19:23:34 -07:00

emails

fix: prevent session poisoning from empty partial-stream-stub assistant turns

2026-07-27 19:23:34 -07:00

README.md

fix(ci): make tests, workflows, and attribution reliable under load (#66373 )

2026-07-17 20:55:24 +00:00

README.md

This directory replaces appending entries to AUTHOR_MAP in scripts/release.py. The old dict caused constant merge conflicts when several salvage PRs landed at once — every PR edited the same lines of the same file. Here, each mapping is its own file, and file additions never conflict.

Adding a mapping

One file per commit-author email, under emails/:

python3 scripts/add_contributor.py <email> <github-login>
# or by hand:
echo "<github-login>" > contributors/emails/<email>

File name = the exact commit-author email (as shown by git log --format='%ae').
File content = the GitHub login on the first non-comment line. Lines starting with # are comments (use them for the PR reference).

Example — contributors/emails/jane.doe@example.com:

janedoe
# PR #12345 salvage (gateway: fix session key routing)

Rules

Do NOT add new entries to AUTHOR_MAP in scripts/release.py. That dict is frozen legacy data; the release tooling merges it with this directory (directory entries win on duplicates).
GitHub noreply emails (<id>+<login>@users.noreply.github.com and <login>@users.noreply.github.com) auto-resolve — no file needed.
The Contributor Attribution Check CI job fails a PR whose commits carry an unmapped email; the failure message prints the exact command to run.

README.md

Contributor email → GitHub login mappings

Adding a mapping

Rules