Both screens that follow a stream retried an `ApiException` and let
everything else through, and `Sse.run` opened its connection on a line
outside the `try` that maps failures onto that type. So a failure at open
time, or anything the framing did not expect, reached the top of the app
and closed it -- from a screen whose own comment says failures there are
deliberately quiet, because the listing already carries every state the
stream would have brought.
The open moves inside the guarded region, and both loops now retry on any
exception while rethrowing `CancellationException`, which is the screen
leaving rather than a failure -- swallowing that one would leave the loop
reconnecting to a stream nobody is watching.
This is hardening on the path that runs when a screen with a stream opens,
not a diagnosed fix: an import list loading against a server missing the
events route, and against 121 real transcripts, does not crash here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Leaving the import screen used to cancel the batch it had started: the
request was the work, so the coroutine that owned it died with the screen
and coming back showed no sign anything had happened. A half-imported
session is the expensive kind of missing -- the row is back looking
untouched, and taking it again is the second `--resume` the import path
exists to prevent.
So the work runs on the server now. Delete and a new per-session import both
answer 202 and spawn the work, and `session::pending` is the record of it:
what is running, and how the last attempt failed. The phone reads that two
ways and needs both. Every row of the listing carries `pending` and `error`,
which is what a phone that was asleep, out of range or freshly opened has to
go on; `GET /setups/{id}/importable/events` streams the changes, which is
what makes a screen somebody is watching change by itself.
Neither alone is enough, and that is not theoretical. A broadcast has no
memory, so an operation that started and finished while the stream was still
connecting was one nothing would ever be said about -- with responses held
back far enough to make it visible, one row of a pair of deletes cleared and
the other sat on "waiting" for good. The screen now asks again after a
handover when anything still looks outstanding, and takes its row states
from that answer rather than from what it remembers.
The single tap still waits, because "take me to it" needs the session that
was made and 202 does not carry one. Both paths go through the same `spawn`
so they cannot drift about what importing means.
Resolving one importable session no longer lists every one of them:
`import::find` is the same script with one glob narrower, which takes the
import seed off the 3.7-second full scan that `delete` came off earlier.
The SSE connection and its framing are now `Sse`, shared with the session
transcript stream rather than written a second time.
irisandClaude Opus 5