Specify explicit ZNG format from file loader #3026
Merged
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.
The "auto-detect failure messages" described in the 4th bullet at #3025 were not something I expected to see. As far as I can tell the
zq
-based shaper is always present in Zui's "file loader" pipeline (but this is something I'm hoping can be confirmed via review!) By defaultzq
will always output binary ZNG in such a pipeline. Normally aload
operation to the Zed lake will always happily auto-detect binary ZNG input so this has not generally been a problem. However my repro details in brimdata/super#3865 (comment) show that thismun.json
test data from #3025 seems to pose a unique challenge becausezq
's ZNG output from reading that particular JSON happens to failload
via auto-detect.While that Zed issue remains a mystery for the moment, it seems we can avoid it entirely and address the main #3025 symptom by explicitly specifying ZNG as the expected load format.
Here's verification of the change in this branch fixing the main #3025 symptom.
Demo.mp4