Ilia Denisov
9f7c9099bc
Synchronous translation on read (Stage D) blocks the HTTP handler on translator I/O. Stage E switches to "send moments-fast, deliver when translated": recipients whose preferred_language differs from the detected body_lang are inserted with available_at=NULL, and an async worker turns them on once a LibreTranslate call materialises the cache row (or fails terminally after 5 retries). Schema delta on diplomail_recipients: available_at, translation_attempts, next_translation_attempt_at, plus a snapshot recipient_preferred_language so the worker queries do not need a join. Read paths (ListInbox, GetMessage, UnreadCount) filter on available_at IS NOT NULL. Push fan-out is moved from Service to the worker so the recipient only sees the toast when the inbox row is actually visible. Translator backend is now a configurable choice: empty BACKEND_DIPLOMAIL_TRANSLATOR_URL → noop (deliver original); populated → LibreTranslate HTTP client. Per-attempt timeout, max attempts, and worker interval all live in DiplomailConfig. The HTTP client itself is unit-tested via httptest (happy path, BCP47 normalisation, unsupported pair, 5xx, identical src/dst, missing URL); worker delivery + fallback paths are covered by the testcontainers-backed e2e tests in diplomail_e2e_test.go. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Backend migrations
Goose migrations embedded into the backend binary by embed.go. Applied
at startup before any listener opens (see internal/postgres).
Pre-production single-file rule
While the platform is not yet in production, every schema change goes
into the existing 00001_init.sql file rather than a new
00002_*-prefixed file. The intent is to keep the schema in one
canonical place so reviewers and developers do not have to reconstruct
the latest shape from a chain of incremental migrations.
Operationally this means that pulling a branch with schema changes requires a fresh database — the only consumer today is local development and integration tests, both of which spin up disposable Postgres instances.
Remove this rule before the first production deployment. From that point on every schema change must be a new migration file with a monotonically increasing prefix, and
00001_init.sqlbecomes immutable history.
If you need to make a change, edit 00001_init.sql directly. Down
migrations should still be kept in sync (they live at the bottom of the
file — currently a single DROP SCHEMA backend CASCADE).