Skip to content

commit_schedule applies a stale diff snapshot (no re-validation at commit) #42

@chiptus

Description

@chiptus

Problem

The schedule import is two phases: diff-schedule computes a plan (Analyse), the admin reviews it, then commit-schedule applies it later. The diff is a snapshotcommit_schedule takes no per-edition lock and does no re-validation, so if the underlying data changes between Analyse and Commit (a concurrent edit, or just a slow review) an outdated plan is applied.

Most visible failure mode: setIdsToArchive is built from the orphan list at Analyse time, so a set added/edited after Analyse can be archived based on stale information.

Notes

commit_schedule is already a single atomic transaction, so a plain pg_advisory_xact_lock would only serialize concurrent commits — it would not make a stale snapshot fresh. A real fix needs re-validation / optimistic concurrency, e.g.:

  • pass a diff version/hash (or the edition's updated_at watermark) from Analyse through to Commit and re-check it inside commit_schedule, aborting if the edition changed; or
  • recompute the orphan set inside the commit transaction rather than trusting setIdsToArchive from the payload.

Severity

Low for a single-core-team admin tool with infrequent imports, but worth hardening before the importer sees heavier or concurrent use.

Context

Split out of the PR #31 review (schedule-ingestion). Deferred deliberately — the correct fix is more than a lock.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions