From 6ff2706ff7d993dffa172fe30b50b4e9dca7cf96 Mon Sep 17 00:00:00 2001 From: Ruben Fiszel Date: Sat, 5 Sep 2026 05:35:45 +0200 Subject: [PATCH] docs: a dbt state read outruns successive publications, not one Co-Authored-By: Claude Opus 5 (1M context) --- docs/dbt-runtime.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/dbt-runtime.md b/docs/dbt-runtime.md index 8f764a79ee..443e363983 100644 --- a/docs/dbt-runtime.md +++ b/docs/dbt-runtime.md @@ -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.