-
Notifications
You must be signed in to change notification settings - Fork 875
fix(encoding): prevent bits_per_value=0 in FullZipLayout for FSL with AllNull child #9130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
b7f0e01
fix(encoding): prevent bits_per_value=0 in FullZipLayout for FSL with…
westonpace b9ac6b4
fix(encoding): make legacy FSL AllNull pages readable with bits_per_v…
westonpace 87e912a
fix(encoding): convert FSL unreachable! panics to proper errors and d…
westonpace b5bf84d
cargo fmt
westonpace File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes stable v2.1 writers emit
FixedSizeList(has_validity=true) → Constant(None). Lance v11.0.0 is the latest stable release and resolvesstableto v2.1, but itsValueDecompressor::from_fslaccepts only nestedFixedSizeListand a terminalFlat; this terminal reaches_ => unreachable!(). Files written through this new path therefore panic in that released reader. The same-version round-trip test cannot detect this forward-compatibility break. Please keep stable writes on an encoding shape v11 understands (for example, aFlatterminal with masked payload bytes at the actual leaf width), or version-gate this composition to an unstable format.Reproducer against v11.0.0
cargo test -p lance-encoding accepts_nested_constant_fsl_value_encoding -- --nocaptureExpected: the released stable reader accepts the stable v2.1 encoding. Observed:
internal error: entered unreachable codeinValueDecompressor::from_fsl.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The old writer would have crashed without this change. We are not making things worse in terms of compatibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The old writer failure is the bug being fixed, but it does not make the new stable encoding forward-compatible: this patch makes a v2.1 file readable by the current reader while the released stable v11 reader still panics on its nested
Constantterminal. The repository contract requires every new stable-format write to remain readable by the released stable reader, even when the old writer could not successfully produce that edge case, so this finding remains.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I accept this as a known risk. Masked payload bytes would be inefficient and this is a fairly niche corner case already.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I guess I'll try and fix it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The follow-up commit only permits zero-width pages in the current FullZip scheduler; it does not change
fsl_to_encoding, which still emits stable v2.1FixedSizeList → Constant. The released v11 reader therefore still reaches its unsupported terminal, so the compatibility finding remains.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct. I am accepting (and have documented) this compatibility gap. The old writer created files that failed anyways. The new writer creates files which panic instead of error, which is unfortunate. However, the compatibility path could lead to 1000x+ increase in storage cost for these types and that is unacceptable. A break in compatibility is the best path forward for this niche case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The storage-cost concern rules out the padded stable encoding, but not the other cited path: put this composition behind an unstable format version. Stable-format forward compatibility is an explicit repository contract, so documenting a v2.1 exception cannot waive it; this finding remains.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current head contains only a formatting change and does not alter this assessment. Version-gating the new composition avoids the padded storage cost while preserving the explicit stable-format compatibility contract, so the finding remains.