The application a restored snapshot runs on: a restore is an app update, as
on a phone — the device and the session stay, while the version and every
fact bound to it are the presented build's ("the library users get is always
the latest version"). A snapshot of another released version is therefore
replaced by defaultApplication as a whole; a snapshot of the same version
keeps its stored literals and only adopts a version-bound field it omits (the
GraphQL doc-id table, GRAPHQL_OMIT_PRETTY, the Direct inbox mode, the
feed/timeline wire, the media like and repost wires, the reels-tray page
size, the launch's shopping experiments and AI-bot count, the routing-map
sample the build writes, the adaptive-UI flag, the Bloks prism palette, the
Bloks theme bloksThemeParams, its INTERNAL_INFRA_THEME spelling and the
bk_client_context shape bloksClientContext), so a
snapshot made between a version bump and this wiring still resolves the new
ids, form shape, inbox mode, feed wire, media wires, tray page size, launch
constants, palette and Bloks theme.
The zero-rating table is settled both ways: a stored ZERO_HEADERS table
does not survive when the presented profile has none (the 450+ wire), so a
restored client cannot keep sending x-zero-balance/x-zero-eh the app
stopped sending; a profile that carries the table adopts it when the stored
snapshot omits it. The Bloks theme and its INTERNAL_INFRA_THEME spelling are
settled the same way: the reference pre-451 build carries neither, so a
stored theme does not survive a restore onto it, and a profile that carries
them adopts them when the stored snapshot omits them. The bk_client_context
shape bloksClientContext rides with the theme: a profile that declares none
sends the reference Android order, so a stored shape does not survive it, and
a profile that declares one adopts it when the stored snapshot omits it.
The application a restored snapshot runs on: a restore is an app update, as on a phone — the device and the session stay, while the version and every fact bound to it are the presented build's ("the library users get is always the latest version"). A snapshot of another released version is therefore replaced by
defaultApplicationas a whole; a snapshot of the same version keeps its stored literals and only adopts a version-bound field it omits (the GraphQL doc-id table,GRAPHQL_OMIT_PRETTY, the Direct inboxmode, thefeed/timelinewire, the media like and repost wires, the reels-tray page size, the launch's shopping experiments and AI-bot count, the routing-map sample the build writes, the adaptive-UI flag, the Bloks prism palette, the Bloks themebloksThemeParams, itsINTERNAL_INFRA_THEMEspelling and thebk_client_contextshapebloksClientContext), so a snapshot made between a version bump and this wiring still resolves the new ids, form shape, inboxmode, feed wire, media wires, tray page size, launch constants, palette and Bloks theme.The zero-rating table is settled both ways: a stored
ZERO_HEADERStable does not survive when the presented profile has none (the 450+ wire), so a restored client cannot keep sendingx-zero-balance/x-zero-ehthe app stopped sending; a profile that carries the table adopts it when the stored snapshot omits it. The Bloks theme and itsINTERNAL_INFRA_THEMEspelling are settled the same way: the reference pre-451 build carries neither, so a stored theme does not survive a restore onto it, and a profile that carries them adopts them when the stored snapshot omits them. Thebk_client_contextshapebloksClientContextrides with the theme: a profile that declares none sends the reference Android order, so a stored shape does not survive it, and a profile that declares one adopts it when the stored snapshot omits it.