IGPAPI
    Preparing search index...

    Type Alias LoginAccountRecoveryDialog

    LoginAccountRecoveryDialog:
        | { kind: "continue"; serverParams: Record<string, unknown> }
        | { kind: "unreadable" }

    The last-resort-recovery (LRR) identification-error dialog the login response can escalate to: HTTP 200 with no login_response, no 2FA context and no status: fail — instead the account-lookup failure state (lookup_query_not_associated_with_account), the identification-error dialog flag (error_info: generic_error_dialog nearby) and a Continue button that opens the ap.two_step_verification.challenge_picker recovery flow. This is not 2FA: the app-id namespace is ap., the flow type unvetted, and the server escalates here from repeated logins off an unvetted device while 2FA is pending.

    The two outcomes are separate members, so "recognized but unreadable" has no field that could also mean "not recognized".

    Type Declaration

    • { kind: "continue"; serverParams: Record<string, unknown> }
      • Readonlykind: "continue"
      • ReadonlyserverParams: Record<string, unknown>

        server_params of the dialog's Continue action (context_data, aac, device_id, screen id method_picker), read verbatim from the parsed tree. The challenge picker is fetched with exactly these params.

    • { kind: "unreadable" }
      • Readonlykind: "unreadable"

        The dialog is recognized, but there is nothing to continue with: the Continue action names no readable params (the literal decoder refused a value) or carries an empty map, which cannot open the picker.

    Settings

    Member Visibility