fix(state): self-heal missing session parent row on transcript writes

[shali10]

What

append_message / append_messages_batch insert into messages with a FOREIGN KEY to sessions. A missing parent row — deleted by cleanup, or never created after a transient create_session failure — raises FOREIGN KEY constraint failed and aborts the whole turn, surfacing as a misleading "session storage could not be written" warning.

Change

Ensure the parent row exists (INSERT OR IGNORE INTO sessions) before writing messages in both write paths, so a missing row can never destroy a turn.

Context

Observed on a long-running gateway where a session row vanished (cleanup race) and every subsequent transcript write failed until manual repair.

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

fix(state): self-heal missing session parent row on transcript writes

• hermes_state.py (~9149-9162, ~9272-9280): the FK self-heal materializes a synthetic sessions row (source='unknown', fresh started_at, no end_reason, no messages) whenever the parent is missing. That phantom row will surface in session listings/stats and in any retention/cleanup keyed on source or started_at, and can keep alive exactly the kind of row a cleanup pass deleted. Suggest checking cursor.rowcount and logging a warning when the heal actually inserts, and stamping the row distinctly (e.g. source='self-healed') so tooling can filter it out.
• The previous behavior aborted the turn loudly on FK failure; now the root cause (row deleted by cleanup, or a transient create_session failure) is silently absorbed. A WARNING-level log at the heal site with the session_id would make future "where did my session go" debugging much cheaper.
• The exact same SQL string is duplicated in both _do blocks — consider extracting a small _ensure_session_row(conn, session_id) helper so the two heal paths cannot drift.

[shali10]

Closing as superseded.

The maintainer triage on #123583 (teknium1, 2026-09-26) reviewed this PR directly: right instinct, wrong layer. The store cannot know the row's identity — source, model, gateway routing key, profile, parent — so INSERT OR IGNORE INTO sessions mints a source='unknown' phantom that later bookkeeping cannot tell from a real session. The agent already holds every one of those fields via _ensure_db_session, so the class fix belongs there.

Since then:

• the agent-side heal landed as fix(agent): heal a session row deleted under a live agent (#123583) #123641, following the triage's fix direction;
• the remaining half of that direction — refusing a delete while a turn still owns the conversation — is proposed in fix(sessions): refuse to delete a session row a live turn still owns (#123583) #123725.

Nothing from this branch is carried into either. Thanks to @teknium1 for the review.