otherwise — the alternative branches of an AndroidIgpapi call.
main receives the screen the entry names (screen:) or one of the first
screens its stored value leads to. The app can show another screen instead:
the server raises a challenge over any effect the screens run — a request of
the start, an action or an edge inside main — and a branch is where you
answer each screen of it (the method choice, the code entry, the captcha).
otherwise is that description — one branch per screen definition of the
platform (a challenge screen or any other), each receiving that screen's own
handle — and defineOtherwise builds it once:
The effect the challenge interrupted failed — at the low level a challenge is
a failure — and the screens catch that failure where they run the effect:
the challenge comes up, the branch of each screen it shows runs, screen after
screen, until it is closed (select-method → enter-code → closed: one constant
covers a chain of any length), and then that effect runs again, whole —
the action, the edge, the request of the start — so a multi-step action sends
the requests it had already sent before the refused one a second time, and the
start or main goes on from it. Owner, 2026-10-27: «на уровне интерпретатора
скринов мы эту ошибку перехватываем… и когда челленж закрылся, мы повторяем тот
эффект, который упал с этим челленджем»; «не тот же прерванный запрос, а тот
же эффект». The entry resolves with main's result; what a branch answers is
discarded, because its job is only to get past the detour.
What the branches cannot settle stops the call with the typed
UnexpectedScreenError: a screen no branch covers, a branch that leaves
its own screen in front, and the same effect interrupted again right after its
challenge closed (no loop). A branch's own error, and a challenge step the
library does not model, stop it the same way, as the same tagged object. None
of them reaches main's error channel: a screen action inside main never
fails with IgCheckpointError (see AndroidMainError).
otherwise— the alternative branches of anAndroidIgpapicall.mainreceives the screen the entry names (screen:) or one of the first screens its stored value leads to. The app can show another screen instead: the server raises a challenge over any effect the screens run — a request of the start, an action or an edge insidemain— and a branch is where you answer each screen of it (the method choice, the code entry, the captcha).otherwiseis that description — one branch per screen definition of the platform (a challenge screen or any other), each receiving that screen's own handle — anddefineOtherwisebuilds it once:The effect the challenge interrupted failed — at the low level a challenge is a failure — and the screens catch that failure where they run the effect: the challenge comes up, the branch of each screen it shows runs, screen after screen, until it is closed (select-method → enter-code → closed: one constant covers a chain of any length), and then that effect runs again, whole — the action, the edge, the request of the start — so a multi-step action sends the requests it had already sent before the refused one a second time, and the start or
maingoes on from it. Owner, 2026-10-27: «на уровне интерпретатора скринов мы эту ошибку перехватываем… и когда челленж закрылся, мы повторяем тот эффект, который упал с этим челленджем»; «не тот же прерванный запрос, а тот же эффект». The entry resolves withmain's result; what a branch answers is discarded, because its job is only to get past the detour.What the branches cannot settle stops the call with the typed UnexpectedScreenError: a screen no branch covers, a branch that leaves its own screen in front, and the same effect interrupted again right after its challenge closed (no loop). A branch's own error, and a challenge step the library does not model, stop it the same way, as the same tagged object. None of them reaches
main's error channel: a screen action insidemainnever fails withIgCheckpointError(see AndroidMainError).