From ab3f76564a7e980b1680abf33b2897bc9e7af0ff Mon Sep 17 00:00:00 2001 From: Ruben Fiszel Date: Sat, 5 Sep 2026 05:54:40 +0200 Subject: [PATCH] docs: name both ways a dbt state read can fail Co-Authored-By: Claude Opus 5 (1M context) --- docs/dbt-runtime.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/dbt-runtime.md b/docs/dbt-runtime.md index 443e363983..b9bee6573f 100644 --- a/docs/dbt-runtime.md +++ b/docs/dbt-runtime.md @@ -1270,8 +1270,9 @@ had. The objects the commit displaced are dropped afterwards, never before, sinc a reader that has already read the row is about to fetch them; a reader that 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 +publications can each overtake one; an unmoved row whose objects are gone is the +error that means what it says, and a bound on the re-reads is the other, for a +project republishing faster than a run can read. 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.