RecordQueryFirstOrDefaultPlan mishandles continuation when resuming cursor #3219
Assignees
Labels
Comments
alecgrieser
added
bug
alecgrieser
changed the title
alecgrieser
added a commit
to alecgrieser/fdb-record-layer
that referenced
this issue
Mar 3, 2025
…nfinite loops The `RecordQueryFirstOrDefaultPlan` constructs a special cursor which has cardinality at most one. The continuation it returns back to the user is not based on the inner cursor but only on whether the cursor has returned any data. Previously, we were taking the `FutureCursor`'s continuation (which is always `\x00`) and giving it back to the `inner` plan, which would generally result in the plan resuming from the beginning. That is not the appropriate way to interpret the continuation, so this updates the logic to instead skip creating the inner cursor if we get a non-beginning continuation, which is in line with what the `FutureCursor`'s continuation means. This fixes FoundationDB#3219.
alecgrieser
added a commit
to alecgrieser/fdb-record-layer
that referenced
this issue
Mar 3, 2025
…nfinite loops The `RecordQueryFirstOrDefaultPlan` constructs a special cursor which has cardinality at most one. The continuation it returns back to the user is not based on the inner cursor but only on whether the cursor has returned any data. Previously, we were taking the `FutureCursor`'s continuation (which is always `\x00`) and giving it back to the `inner` plan, which would generally result in the plan resuming from the beginning. That is not the appropriate way to interpret the continuation, so this updates the logic to instead skip creating the inner cursor if we get a non-beginning continuation, which is in line with what the `FutureCursor`'s continuation means. This fixes FoundationDB#3219.
alecgrieser
added a commit
to alecgrieser/fdb-record-layer
that referenced
this issue
Mar 3, 2025
…nfinite loops The `RecordQueryFirstOrDefaultPlan` constructs a special cursor which has cardinality at most one. The continuation it returns back to the user is not based on the inner cursor but only on whether the cursor has returned any data. Previously, we were taking the `FutureCursor`'s continuation (which is always `\x00`) and giving it back to the `inner` plan, which would generally result in the plan resuming from the beginning. That is not the appropriate way to interpret the continuation, so this updates the logic to instead skip creating the inner cursor if we get a non-beginning continuation, which is in line with what the `FutureCursor`'s continuation means. This fixes FoundationDB#3219.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
RecordQueryFirstOrDefaultPlancurrently does not resume from a continuation correctly. In particular, it creates aFutureCursorover an inner, and that future cursor will return 1 value--either the first value from the underlying cursor or the "default" value. But the future cursor's result always has constructs a single continuation value (the byte string\x00) which is supposed to indicate "the element has been completed". However, we are currently threading that value through into the child plan, which generally will result in resuming the underlying scan from the beginning.This is causing problems when trying to run some
EXISTSqueries in "force continuations' mode. Those queries are looping forever, because the cursor is not being advanced by the continuation during each run (because it is re-running underlying scans).There are also problems with out-of-band errors not being handled correctly; see: #3220. However, that is a slightly different problem, and we should be able to fix this (which enables turning on force_continuations tests) and then update the continuation format in a future version.
The text was updated successfully, but these errors were encountered: