v1.7.3
← Back to Releases

v1.7.3

The v1.7.3 release is for self-hosters only. It lets instances on v1.3.x or older upgrade again, and every release is now tested against upgrades from real published versions. If you use Econumo at app.econumo.com, there’s nothing new for you here.

Self-hosting Econumo? Everything in this release is in For self-hosters at the end of this page.

For self-hosters #

Upgrading is a drop-in: pull the new image and restart. Migrations run on boot and add one entry to schema_migrations (20261101000000). The API doesn’t change.

Instances on v1.3.x or older can upgrade again #

An instance on v1.3.x or older that held a deleted account with a non-zero balance could not boot v1.7.0–v1.7.2. The first boot stopped with no such column: recipient_sort_key, on both SQLite and PostgreSQL.

A data migration that zeroes the balances of deleted accounts wrote through the current code, before a later migration had added a column that code needs. That migration now runs after every schema change it depends on:

  • An instance stuck on this error recovers by moving to v1.7.3. Nothing was lost, and the boot picks up where it stopped.
  • For each deleted account still holding a balance, the migration writes a Balance adjustment (account deleted) correction.
  • Instances that already ran this step, which is every instance on v1.4.0 or later, run it again and nothing changes. Fresh installs were never affected.

Every release is now tested against real upgrades #

Until now, every test started from an empty database, so none could catch a migration that misbehaves only on a database an older release left behind. That is how the sign-in bug fixed in v1.7.2 reached production.

CI now takes the newest patch of every minor line from v1.2 on. On SQLite and PostgreSQL, it seeds a database through that release’s own API, upgrades it with the new build, and checks:

  • the schema and migration order
  • that sessions and personal access tokens still work
  • the stored data, including balances and budget figures
  • that writes still work on the migrated rows

New releases are picked up automatically. The suite found the bug above on its first run. Thanks to @Sam-Hui-dot for the idea and the prototype (#227).

GitHub release #