Jobs, ownership and synchronization
Avichive uses jobs and controlled data transfers to keep expensive processing out of web requests and to connect local archive work with production browsing. The important boundary is not simply development versus production: different records have different owners, and their synchronization rules follow that ownership.
This explanation is grounded in application revision e76e74c, inspected October 13, 2026, and its operating documentation. It describes implementation and documented procedures, not a newly exercised deployment or current queue-health report.
Jobs make work explicit
Original uploads, image preparation, video conversion and analysis can take longer than a page request. GoodJob stores and runs application jobs, while domain records retain the meaningful state: selected upload items, analysis batches, failures and completed results. A queued job alone is not evidence that the corresponding output is ready.
Bounds make recovery and supervision practical. Upload runs select finite work; preview preparation has source-size limits; face and era analysis use selected batches. A per-batch concurrency limit prevents simultaneous result handlers, although the results code explicitly notes that counters are not idempotent. This is controlled asynchronous processing, not a blanket exactly-once guarantee. Analysis result job (app/jobs/process_batch_results_job.rb:3).
Ownership determines the transfer
| Data | Authority | Transfer or serving rule |
|---|---|---|
| Scanner inventory | Go scanner | Rails reads it; ordinary incremental packages do not replace scanner occurrences |
| Core archive metadata and curation | Development | Allowlisted incremental rows upsert into production |
| Era definitions, clues and memberships | Production | Development mirrors revisions and forwards edits |
| People, analyses and face annotations | Local development | Full replacement section propagates portable records to production |
| Face vectors and matching state | Local development | Stay local |
| Active Storage records and derivative readiness | Each environment | Generated and tracked independently |
| Upload-run and job execution history | Each environment | Operational state does not become portable archive truth |
Deployment ownership (docs/DEPLOYMENT.md:203), incremental table allowlist (app/services/db_sync/tables.rb:13), people replacement (app/services/db_sync/replace_tables.rb:4).
For example, an uploaded original’s stable URI can synchronize while production reads the same B2 object. A development thumbnail status cannot establish a production attachment: the destination needs its own corresponding derivative records. Conversely, a locally deleted face annotation needs replacement semantics so a stale production copy does not survive forever.
Portable identity, consistent snapshots
Incremental exports select allowlisted metadata fields. Paths and content hashes resolve destination relationships instead of assuming local numeric IDs match. Era suggestions carry portable identifiers and versioned evidence; curated era definitions follow their separate authority protocol.
Exports use a consistent, read-only repeatable-read snapshot so related tables describe one database view. Uploading a package is not the same as importing it. Confirmed-import markers allow development to advance its synchronization watermark after production has accepted the package, avoiding gaps caused by treating export success as receipt. Export snapshot (app/services/db_sync/incremental_export.rb:13), import markers (app/services/db_sync/import_marker.rb:3).
These details address concrete failure modes: a person missing from a related face export, a changed row skipped by an early watermark, or destination media reported ready without an attachment. They do not eliminate the need to inspect failures and reconcile state.
Restore and deployment boundaries
A full database restore is a separate, potentially destructive operation, not routine incremental synchronization. Production-owned eras, independent attachments, owner flags and other environment-owned records require their documented preservation boundaries. Rebuilding the scanner catalog is likewise not a safe casual substitute for a coordinated migration: application relationships depend on that evidence.
The app’s deployment documentation states that pushing its main branch deploys. That is an operational trigger, not a reason to combine content review with release. This guide supplies an explanation, not a command sequence for replacing a production database. Deployment and transfer procedures (docs/DEPLOYMENT.md).
See cloud preservation for object integrity, life eras for reverse authority flow, and photo analysis for local inference and production read views.