Skip to content

Site deployment: cleaner wait for initial database replication - #500

Merged
timbeccue merged 4 commits into
mainfrom
fix/site-startup-wait
Oct 22, 2026
Merged

timbeccue merged 4 commits into
mainfrom
fix/site-startup-wait

Conversation

@timbeccue

@timbeccue timbeccue commented Oct 13, 2026 •

Copy link
Copy Markdown
Contributor

Problem

On a fresh site deployment the stacking supervisor starts as soon as Postgres is healthy, before banzai-cache-init has created the instruments table or replication has filled it. Its first query then fails, docker restarts it, and the container crash-loops with error logs until the database catches up. This isn't a big problem besides the fact that it pollutes the logs with lots of noise.

Fix

In the startup camera discovery lookup, sleep for 30s and retry instead of craching and relying on docker to restart. Log 'info' the first time this happens, and then once every 10 minutes.

Note: this change has been running in the branch deployed to sites for a while with no issues so far.

@timbeccue timbeccue changed the title Wait for database initialization during stacking supervisor startup Wait for the site database instead of crash-looping at startup Oct 21, 2026
@timbeccue
timbeccue marked this pull request as ready for review October 21, 2026 06:33
@timbeccue
timbeccue requested a review from cmccully October 21, 2026 06:34
@timbeccue timbeccue changed the title Wait for the site database instead of crash-looping at startup Site deployment: cleaner wait for initial database replication Oct 21, 2026

@cmccully cmccully left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lgtm

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

The missing-table recovery path and propagation of unrelated database errors need regression coverage.

1 open issue
What changed in this PR

This PR reduces stacking-supervisor crash-loop noise while a new site's database initializes and replicates.

Changes:

  • Retry camera discovery every 30 seconds when the table or matching cameras are unavailable.
  • Log waiting status immediately, then every 10 minutes.
  • Update the supervisor test to verify startup after cameras become available.
File Description
banzai/​tests/​test_smart_stacking.py Tests retrying empty discovery and subsequent worker startup.
banzai/​stacking.py Adds startup retries, missing-table handling, and throttled logging.

Review effort: Balanced

Comment thread banzai/stacking.py
Comment on lines +188 to +191
except ProgrammingError as exc:
if not isinstance(exc.orig, UndefinedTable):
raise
instruments = []
@timbeccue
timbeccue merged commit 1a9a924 into main Oct 22, 2026
10 checks passed
@timbeccue
timbeccue deleted the fix/site-startup-wait branch October 22, 2026 20:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants