fix(dump): sortAt must never trust the Image.sortAt column (no-backfill decision)

[JustMaier]

Context

Follow-up to #326 (merged W2-1). With the no-backfill decision (92M historical Image rows stay un-backfilled), the merged dump copy_query's COALESCE(i."sortAt", GREATEST(...)) shape is wrong: COALESCE prefers the column when non-null, and the historical column is NOT NULL but stale — now()-at-migration garbage (measured on prod: 88.1% mismatch vs. the correct GREATEST value, clustering ≈ createdAt). The dump would have ingested that garbage for ~92M rows.

Fix

The dump now computes sortAt as a pure GREATEST(post.publishedAt, scannedAt, createdAt) and never reads i."sortAt" at all.

Why SQL-only, not a dump computed_field

Two options were on the table:

1. Drop sortAt from copy_query, compute it as a dump computed_field max(publishedAtSecs, scannedAtSecs, createdAtSecs) (using the posts-enrichment publishedAtSecs).
2. Keep it in SQL as pure GREATEST, no COALESCE.

Picked (2) — mechanically simpler, and (1) has a real blocker: dump top-level computed_fields evaluate via def.eval_indexed(&indexed_fields_buf, col_idx, None) where indexed_fields_buf is filled from the raw CSV row (dump_processor.rs:1970, row.fill_indexed_fields(...)) before enrichment runs (dump_processor.rs:1984, enrichment_mgr_ref.enrich_row_indexed_into(...)). A dump-level computed field therefore cannot see the posts-enrichment's publishedAtSecs without extending that evaluation-order code — not something to do inside a config-only fix. Pure SQL needs no code changes and is provably correct by inspection.

The ops-emission pairing (unchanged, and why)

The steady-state ops trigger's sortAtUnix expression (shared_ops_fields: [sortAtUnix], COALESCE(NEW."sortAt", GREATEST(...))) is unchanged and stays COALESCE-shaped — trusting the column there is safe for a different reason than the dump: model-share's image_sort_at_before (BEFORE INSERT OR UPDATE) trigger recomputes NEW."sortAt" on every write that reaches PG, so any row this ops trigger fires on is correct-on-write by construction. The dump has no such guarantee — it reads all 92M+ rows regardless of whether they were ever touched post-cutover.

Pinned this pairing in comments on both trigger blocks in deploy/configs/sync-config-civitai.yaml:

"ops emission may trust the column ONLY because image_sort_at_before recomputes it on every write; the dump must NEVER trust it (92M pre-trigger rows are stale)."

Test

src/pg_sync/sync_config.rs::test_dump_sortat_never_trusts_the_column (loads the real deploy config):

• dump copy_query has no COALESCE and no i."sortAt" read reference;
• computes sortAt via a type-correct extract(epoch from GREATEST(...))::bigint (single timestamp expression, never a bigint/timestamp mix — [PR-B3]);
• the ops trigger's sortAtUnix track field remains COALESCE-shaped (guards against the pairing getting flattened by a future edit).

cargo test --lib --features pg-sync (skip test_min_tracked_value_after_expansion, known deadlock): 1250 passed, 8 ignored, 0 failed.

🤖 Generated with Claude Code