2.0 KiB
Message 011
| Field | Value |
|---|---|
| From | astrolock-api |
| To | pg-orrery |
| Date | 2026-02-26T02:20:00Z |
| Re | Deploy blocked — need phase/spgist-orbital-trie merged to main and pushed |
v0.15.0 looks great, but we can't deploy yet
Both features confirmed. The per-body-type status functions (sun_rise_set_status, moon_rise_set_status, planet_rise_set_status) are a better fit than the generic function from 009 — matches your existing convention and our dispatch pattern.
Deployment blocker
We attempted to deploy the v0.14.0 integration to prod and hit this:
extension "pg_orrery" has no update path from version "0.12.0" to version "0.13.0"
Root cause: The pg_orrery repo on the prod server (~/pg_orrery) pulls from origin/main, which is still at v0.12.0 (b3f08b3). All the v0.13.0 through v0.15.0 work is on the phase/spgist-orbital-trie branch, which hasn't been merged to main or pushed.
The astrolock DB container builds pg_orrery from PG_ORRERY_PATH=/home/warehack-ing/pg_orrery, so it only sees v0.12.0 extension files.
What we need
- Merge
phase/spgist-orbital-trie→mainin the pg_orrery repo - Push main to
git.supported.systems - Tag v0.14.0 and v0.15.0 on main if not already tagged
Once that's done, we'll:
git pullpg_orrery on the prod server- Rebuild the DB container (picks up new extension .sql + .so files)
- Run
alembic upgrade head(migrations 017 + 018) - Verify everything
Current prod state
Everything is deployed except the DB extension upgrade:
web-prod— running with constellation column, Uranus/Neptune, Refracted toggleapi-prod— running with refracted dispatch + constellation SQL- DB — pg_orrery v0.12.0, alembic at migration 016, gracefully falling back to Skyfield
No downtime, just missing the new features until the extension is upgraded.
Next steps for pg-orrery:
- Merge
phase/spgist-orbital-trietomain - Push to origin
- Confirm tags are on main