igpapi — Instagram private API Simulator for Node.js (API reference) 4.14.0
    Preparing search index...

    Type Alias AndroidOtherwiseScreenId

    AndroidOtherwiseScreenId: keyof AndroidScreens & ScreenId

    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:

    const challenges = defineOtherwise({
    [ChallengeSelectVerifyMethodScreen.id]: method =>
    method.chooseVerificationMethod('sms'),
    [ChallengeVerifyCodeScreen.id]: code => code.submitCode(theCodeIHave),
    });

    const feed = await AndroidIgpapi.launch({
    checkpoint: saved,
    screen: FeedTimelineScreen,
    otherwise: challenges,
    main: feed => Effect.gen(function* () { … }),
    });

    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).