bundleUpdate.sh and denisPublish.sh each called `date +%s`, so a single dual-write
gave the same bytes two different bundle versions -- observed 1785102575 (denis)
and 1785102614 (ota1), 39 seconds apart, for commit b662cd43b.
That is not cosmetic. The bundle version is a path segment in every asset URL the
manifest hands the client:
https://updates.bsky.app/file/1.130.0/<bundle-version>/bundles/<hash>
Both origins mint those URLs against updates.bsky.app, which resolves to whichever
origin Bunny currently points at. So each origin was serving a manifest whose
assets only IT has. A manifest fetched from one origin and assets fetched from the
other 404s -- which is exactly what a rollback of the Bunny origin does if it lands
between a client's manifest fetch and its asset fetch. The dual-write existed to
make rollback safe and was quietly making it unsafe.
Pin the version once in the job and let both scripts inherit it. Both fall back to
`date +%s` when BUNDLE_VERSION is unset, so the single-publisher callers are
unchanged: pull-request-commit.yml (denis only) and `pnpm make-deploy-bundle`.
The fallback uses `:-` rather than `-`, so an empty value also falls back --
`denis publish` rejects a non-numeric bundle version, so an empty one must never
propagate.
This does not make the two manifests byte-identical. createdAt still differs
(21:49:35Z vs 21:50:18Z for the commit above) because ota1's legacy uploader
stamps it server-side on receipt; the client posts a tarball, not a timestamp, so
nothing here can align it. That residual is inert in a way the bundle version was
not: the manifest id is content-addressed on metadata.json and is identical across
origins, so manifestHandler's `currentUpdateID == entry.Manifest.ID` check makes a
client that switches origins see the same update rather than a newer one. It goes
away with the dual-write in Phase 5.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* some progress
another adjustment, testing
another adjustment, testing
fix again
fix again
set default runtime version
fix
test this script
test this script
test this script
add build numbers to the deployment url
clean
give script access to build number
add `useBuildNumberEnv` without a bump
new line
fix missing async
add channel name to deployment url
add updates check on launch for testflight users
ver bump
init updates on launch for native
add `testflight` as default in build submit
add is_testflight check
* disable inline predictions to prevent ios composer jank
* temp bump
* Revert "temp bump"
This reverts commit 44c51134a3.
* adjustments
version bump
adjust
fixes
test
* cleanup and finalize
drop check down to every 15 minutes
adjustments
change to 15 mins
use jq to get version if necessary
rm test on push
figured it out
remove nightly testflight releases
test again again again again again AGAIN ONCE MORE
test again again again again again AGAIN
test again again again again again AGAIN
test again again again again again
test again again again again
test again again again
test again again
test again
test
test
test
run deploy if necessary
run deploy if necessary
run deploy if necessary
run deploy if necessary
run deploy if necessary
remove test message
fix environment
oops
cleanup
merge in changes
* remove unnecessary `workflow_call`
* remove changes that have been merged into main now
* finalize android
update git ignore
rm test stuff from the bundle action
remove test message
test message
fix
test message
test message
few android fixes
few android fixes
fix jq
add a test message
fix slack webhook
create android deployments test 2
create android deployments
add `testflight-android` profile to eas.json
more cleanup
some more cleanup
simplify some logic
remove unnecessary channel
rename to `useOTAUpdates`
* rm test portion
Austin McKinley