starred/windmill
1
0
Fork 0
mirror of https://github.com/windmill-labs/windmill.git synced 2026-09-05 16:03:47 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: name both ways a dbt state read can fail

Browse Source 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Ruben Fiszel
2026-09-05 05:54:40 +02:00
co-authored by Claude Opus 5
parent ddf2603c9e
commit ab3f76564a
1 changed files with 3 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/dbt-runtime.md
+3 -2
View File
@@ -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.