Note the orphaned Postgres app database

Nothing reads it since the engine moved its state to SQLite, but it still
carries the pre-cutover history and an alembic stamp naming a revision that
commit deleted — which reads like a broken migration chain and is not one.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012ue1tkFWB1bcGy3aWhCKpU
This commit is contained in:
2026-08-23 21:03:05 +02:00
co-authored by Claude Fable 5
parent 19bc2810cf
commit 6b77675167
+13
View File
@@ -400,6 +400,19 @@ as an em dash.
## Deferred ## Deferred
- CHORE/OPS: the Postgres `app` database is an orphan on every installation
that predates 73eeec2 (2026-08-21, "Keep the engine's state in SQLite, not
Postgres"). Nothing reads it — the engine's database is `$DATA_DIR/fluksio.db`
and `docker/compose.yml` already puts `db` behind the analytics profile as
"Umami's database, and nothing else's" — but it still holds the pre-cutover
history (dev 17 MB / 43 runs, the hosted instance 15 MB / 4 runs) and is
stamped at `c4e8b2170f93`, a revision the squash deleted. Harmless, and
alarming to read: `alembic_version` says a revision that no longer exists.
Dump it if the history is wanted, then drop the database; on the hosted
instance keep the *container*, because Umami's database is in it. The `db`
service also still bootstraps `POSTGRES_DB=app` by default, which is what
recreates the confusion — `umami` would be the honest default now.
- FEAT/SDK: a traced flow body — `@Flow` over a function whose calls to other - FEAT/SDK: a traced flow body — `@Flow` over a function whose calls to other
nodes build the graph, the way Covalent's lattice does. Rejected for the first nodes build the graph, the way Covalent's lattice does. Rejected for the first
version with reasons in `docs/private/python-api.md` (2.5× the code, two version with reasons in `docs/private/python-api.md` (2.5× the code, two