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

    Variable SCREEN_CHECKPOINT_FORMATConst

    SCREEN_CHECKPOINT_FORMAT: 5

    The checkpoint format this library writes. An older released format keeps decoding, as the root rule of "Only the Latest App Version Exists" says: a checkpoint written by an earlier release of the library is a version of the library, not of the app, and its old fields are read into the current layout. This build writes format 5 and reads format 4 (v4.11.0) beside it; a checkpoint of an unknown or newer format is refused with CheckpointDecodeError, never partially restored.

    The carried platform parts are part of the format. The set of ProcessCheckpointRegistries parts — their keys and their encodings — is as much a checkpoint's format as this number is: adding, removing or renaming a part changes what a checkpoint holds, so it bumps this constant. A part a later format added is absent from an older released checkpoint; it is restored to its declared initial state (ProcessCheckpointPart.initial), which is the state a process of that build held — the fact did not exist there — never a guess about a value the older build stored. A part with no initial makes such a checkpoint undecodable. A checkpoint of the current format must carry every part, and an unknown part is refused (see restoreExtras).

    Format 2 (released in v4.7.0) added a frame's lookup index (the rows an action refreshed) beside its visit index, so a restored frame keeps the two apart exactly as the live one did, and carries the facts a restore continues the process with: the frame's visit (its id, ordinal, start and shown times), a swipeable feed's item in front with its own visit, the process's tray session and the foreground surface trail's navigation source (a screen's module can depend on how it was reached). A restored departure is then the same visit it was before the checkpoint — the item in front's included — and the tray keeps its id. It also adds the interruption: a frame the server brought over the frame below (a challenge), and the root that is one. The platform parts extended it the same way (the Android sign-up screens' registration session, android.registration-session, and the reels viewer's session and visits, android.reels-viewer-views).

    Format 3 drops the telemetry queue from the process part: undelivered events belong to the process that logged them, which delivers them when it closes. A format released in a tag is never changed in place: format 5 reads format 4 instead of rewriting it, and a format this build cannot read (3 and earlier, or an unknown or newer one) is refused.

    Format 4 (released in v4.11.0) adds the Android process's running user flows (android.user-flows, the state x-ig-salt-ids renders) with the readiness of the QPL logger that renders them: a restored process continues the flows the checkpointed one was running, and a checkpoint taken inside a launch's first flight restores a logger that still stamps no header. It also carries the process's timers as a platform part (Android: android.process-timers, the routing-map refresh and the Direct presence re-read with when each next fires and what it repeats, so a restored process fires them when a continued one would). It also carries the MobileConfig configs the process has read with the values it fixed for each (mobileConfig, mobile.mobile-config.ts), so a restored process reads what the checkpointed one read, and the Android quick-promotion stash (android.quick-promotion-stash, each surface's last answered batch: the app persists the answer's time across its own restart, so a restored process does not re-send the batch), and the process's client address (android.client-address, the public IPv4 the server echoed and when, which the reels viewer's tail page re-sends). The process's session origin keeps only whether the stored-session start has begun (begun): the routing map it once carried is the install's, so it travels in the client state's device.

    Format 5 adds two Android platform parts: the throttling detector (android.throttling-detector, the process state behind x-meta-tasos-td-rates / x-meta-tasos-td-signal), so a restored process reports the detector's form and count the checkpointed one held, and the comments sheet's once-only reads (android.comments-sheet-reads), so a restored process skips the restricted-account and shop-eligibility reads the checkpointed one made. Format 4 shipped in v4.11.0 without these parts and with the session origin's earlier shape, so format 4 is not changed in place: it is read. A format-4 checkpoint restores into the format-5 layout with its missing parts at their initial states — the detector's Waiting and the reads' nothing held — because a 4.11.0 process had no such state to save: that is the state it held, not an invented default.