docs: a dbt state read outruns successive publications, not one

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Ruben Fiszel
2026-09-05 05:35:45 +02:00
co-authored by Claude Opus 5
parent 96899e7a57
commit 6ff2706ff7
+4 -2
View File
@@ -1268,8 +1268,10 @@ artifact the committed row still names: a run that fails between its two uploads
or between them and its row, leaves the state pointing at the pair it already
had. The objects the commit displaced are dropped afterwards, never before, since
a reader that has already read the row is about to fetch them; a reader that
loses that race re-reads the row once rather than reporting a state that is
there. What a publication uploaded and then could not commit is dropped on the
loses that race re-reads for as long as the row keeps MOVING, rather than
reporting a state that is there. A reader takes no lock, so successive
publications can each overtake one, and only an unmoved row whose objects are
gone is an error. What a publication uploaded and then could not commit is dropped on the
way out — except after a commit that REPORTED an error, where what was lost may
be only the acknowledgement: dropping then would leave a committed row naming
objects that are gone, so an orphan is the cheaper side to take.