irisandClaude Opus 5
7a02e79613
Deleting a session the server no longer has replaced the whole list with an error. The server answered -- it said "no session <id>" -- so what it told us is about one row, and every other row was still exactly as fetched. The list going away said otherwise. The line between the two scopes is whether the server answered. Answered and refused is about one item and belongs on that item; never answered leaves every row stale against a server that has stopped talking, and that is the list's own state to report. Both cases exist here and had been sharing one slot, which is why the message had to hedge about which it was. So failures acting on one session live in a map keyed by its id and render inside its card. The path out is the next successful load, which clears the map: an entry would otherwise outlive the session it names and reappear against whatever the phone fetched next. The shape is dev-updater's `cardStates`, which solved this first; the rule above is theirs too, and it moves their "gave up waiting" case the other way, to list-level, which is a good sign it is a rule rather than a description of what either of us already had. Verified on the emulator by producing the real failure -- delete a session out from under the app with curl, then delete its stale row from the phone. The refusal appears on that card, the other card is untouched, the list stays, and Refresh clears it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017xn8nHw1tw1R6PtiY1eEtw