The process's incorrect-password dialog poll: at most one poller at a time,
owned by the login flow — the shared step both the login home's action and
the standalone Login run starts it from the wrong-password answer.
The dialog is app behaviour, not a request a caller asks for: the bad-password
answer to send_login_request renders a Bloks dialog that polls its own async
action while the dialog is up, and the app stops when the person closes it.
The library models the dialog's lifetime with this process fact — a new login
attempt closes the previous dialog and its poll — while the dwell itself is
the person's and stays the caller's.
The poller is a fiber of the app process: it is forked into the scope of the
layer that builds this service, so closing the process (the runtime's
disposal) interrupts it, exactly as the app closing stops its dialog. One
value per runtime layer, never in the snapshot: a restored process shows no
dialog it did not open.
Starting and stopping are serialized by the state's own lock: two concurrent
login attempts must still leave one poller, not one each — the attempt that
starts last closes the other's dialog, and an attempt that had to wait for a
poll in flight cannot revive it after another attempt started.
The process's incorrect-password dialog poll: at most one poller at a time, owned by the login flow — the shared step both the login home's action and the standalone
Loginrun starts it from the wrong-password answer.The dialog is app behaviour, not a request a caller asks for: the bad-password answer to
send_login_requestrenders a Bloks dialog that polls its own async action while the dialog is up, and the app stops when the person closes it. The library models the dialog's lifetime with this process fact — a new login attempt closes the previous dialog and its poll — while the dwell itself is the person's and stays the caller's.The poller is a fiber of the app process: it is forked into the scope of the layer that builds this service, so closing the process (the runtime's disposal) interrupts it, exactly as the app closing stops its dialog. One value per runtime layer, never in the snapshot: a restored process shows no dialog it did not open.
Starting and stopping are serialized by the state's own lock: two concurrent login attempts must still leave one poller, not one each — the attempt that starts last closes the other's dialog, and an attempt that had to wait for a poll in flight cannot revive it after another attempt started.