irisandClaude Opus 5
0862b47f76
A session whose transcript will not parse is skipped with only a log line, so from the phone it is indistinguishable from an idle unresponsive one. That is why the outage needed a report from Bryan rather than showing itself. The cause is fixed; the class is not, and it is the "design the unknown state first" rule rather than a bug in one code path. Also rustfmt on the parse path, which the fix landed unformatted. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.0 KiB
3.0 KiB
TODO
Working list from Iris, 2026-09-03. Remove an entry when it lands; annotate one in place when it turns out to need a decision.
App — transcript
- Messages received from other agents are inconsistent — sometimes they
appear, sometimes they don't. Needs a rig. Read the code rather than
measured: a live Claude session only learns of a peer message from the
originobject on a turn'sresult(session/claude/translate.rs), which the CLI attaches to a turn the message started. So a message that arrives mid-turn, or a second one within one turn, has nowhere to be reported — while an imported session, which syncs from the CLI's own file, picks up every one of them. That would show exactly as "sometimes". Confirming it means driving a real stream-json session and sending it messages in both states.
Session settings
- Autocompact belongs in session settings; empty disables it, which is the
default. Iris chose "hand it to the driver" — only where a driver has
auto-compaction of its own. That option was offered on a false premise
and is not buildable yet. It named pi's
set_auto_compaction, but pi was never built as a driver here:session/llama.rstalks tollama-server's OpenAI-compatible endpoint directly, and itscompact()refuses outright. Claude Code's auto-compaction is the CLI's own and nothing in the stream-json control protocol this app uses configures it. So the setting would be stored, passed to a driver, refused by every one of them, and the field would never appear on any session. What is needed first is either a driver that can take it, or a different rule — the server watchingcontextTokensand running/compactitself is the one that would work today, for Claude sessions, and it is the option that was not chosen.
A session the server could not load
- A session whose transcript will not parse is skipped with nothing but a
log line, and from the phone it looks exactly like an idle unresponsive
one.
SessionManager::newcatches a failinglaunchand logs "couldn't relaunch session ", so the session has no pump and no driver: no status, no history, nothing sendable. That is what thetaskNoteincident (fd71d87) looked like from Bryan's phone, and why it needed a report from him rather than being visible in the app.Event::Unreadableremoves the cause that time, but not the class — an unreadableprocess.json, a provider edited away and an unreachable host all reach the same place. This is the "design the unknown state first" rule: a session the server could not load is not a session with nothing to say, and only the phone can show the difference. It needs a status the wire can carry for it — the failure with its reason, reported on the session itself — rather than the reader having to tell it apart from silence.