halkyon-days/halkyon
Watch
1
0
Fork
You've already forked halkyon
 0
Code Issues Pull requests Projects Releases 37 Packages Wiki Activity Actions

fix(deploy): the server starts once more after a deploy with a migration

Browse source 
After v0.13.0's deploy every request to learn.halkyon.eu took a minute or
two and syncs failed, until the server was restarted by hand. The
migration changed a synced table, so the new server, as it first used
the database, found the sync engine's registry of synced tables changed,
and then rebuilt every space's projections in every session until it
stopped (serverpod_offline_sync issue #150). The maintenance run that
applies the migrations doesn't spare it, as AGENTS.md wrongly said.

redeploy.sh now restarts the server once it answers whenever the deploy
brought a migration, and waits for it to answer again: started a second
time, it finds the registry as the first start left it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me>
This commit is contained in:
Tizian 「ティツィアーン」 2026-10-13 22:45:57 +02:00
commit 9b5ea88a8a
Signed by: raisondetredev
GPG key ID: 07F6FCF405488B64
1 changed files with 15 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

15
deploy/redeploy.sh
View file

@ -10,7 +10,8 @@
# - if every new commit is signed by a key in deploy/allowed-signers, as the deployed
# checkout lists them (so no commit can add its own key),
# dumps the database first (the last 3 dumps stay in ~/backups), applies the migrations
# before switching to the new server, and fails unless that server answers afterwards. A failure leaves the checkout at the deployed commit, so
# before switching to the new server, starts it once more after a migration (see below),
# and fails unless that server answers afterwards. A failure leaves the checkout at the deployed commit, so
# running the CI job again retries. By hand, with your own key:
#
# ssh learn-deploy halkyon-learn/deploy/redeploy.sh <commit>
@ -77,6 +78,18 @@ main() {
docker compose up -d --force-recreate --no-deps caddy
fi
wait_until_answering
# After a migration the new server is started once more. The sync engine
# (serverpod_offline_sync v0.0.10) reconciles its registry of synced tables as a
# server first uses the database; when a migration changed a synced table, that
# changes the registry, and the server then rebuilds every space's projections in
# every session until it stops (issue #150): after v0.13.0's deploy every request
# took a minute or two, and syncs failed, until the server was restarted
# (2026-10-13). The maintenance run doesn't spare it. Started again, the server
# finds the registry as the first start left it.
if ! git diff --quiet "$deployed" "$commit" -- ../halkyon_learn_server/migrations; then
docker compose restart server
wait_until_answering
fi
trap - EXIT
docker image prune -f >/dev/null
echo "Deployed $commit."