Two things the corpus runner got wrong about the engine - #20
Merged
Conversation
The corpus itself was right the whole way: 1438 cases, 1438 passed, 0
failed, 0 unsupported against the engine at main. What was red was two
things beside it.
The test for a case ahead of the engine used SELECT 1 as a statement the
engine has not reached, and the engine reaches it: SELECT is a statement
head in ISO 39075 and this engine parses one, so the case came back with
a column called 1 and the runner correctly called that a failure rather
than an unsupported. It is CREATE NODE TABLE now, which the engine
refuses with 42001 and the words "CREATE is not implemented yet". A test
like this is a canary by construction and the comment now says so: the
day CREATE lands it has to pick another spelling.
The javadoc on Cell said {@link #equals}, and Cell is a sealed interface
that declares no equals, so the reference did not resolve and the
release profile failed on it. It points at Object#equals(Object), which
is the method the records generate an override of and the one the
sentence is about.
Verified on a Linux box against the engine at 55382df: the corpus module
is BUILD SUCCESS with RunnerTest 12 of 12, and mvn -P release -DskipTests
package is BUILD SUCCESS.
tamnd
added a commit
to tamnd/zu-go
that referenced
this pull request
Aug 25, 2026
* Carry the rest of the diagnostic record The engine grew four accessors on an error handle and the vendored header did not have them, which is what the engine job in CI notices first: it diffs the header against the one in the engine tree and stops there. The four are zu_error_subject_kind, zu_error_subject, zu_error_graph and zu_error_schema. They are the rest of what ISO 39075 subclause 23.2 asks a diagnostic record to carry. The subject is what the condition is about when it is about something the statement named, split into a kind and a name so that asking whether a failure is about a label is one string compared against one word rather than a sentence parsed for a quoted thing. The graph and the schema are where the statement was running, which are empty together when the failure happened before there was a connection at all. A program that underlines the offending name in an editor is the case this is for. Before this it had to find the name inside English prose, which is the whole reason these are fields. The header is copied from the engine tree rather than edited, so the diff step passes by construction. Closes #25 * Stop naming columns after words the engine reserved Ten words became reserved in the engine and six of them are spelled as aliases in these tests: nothing, sum, count and next, plus the same sum in two of the zusql examples. A reserved word after AS is a syntax error, so the next lib.yml run that moves the vendored pin turns all of them red at the same moment, which is a confusing way to find out. The renames are only in the test text. Nothing in the package names a column, so there is nothing here for a user to notice. Where the Go variable was named after the column it moves with it, so the two still read as the same thing. I swept the other four clients the same way, matching every alias against the reserved and pre-reserved lists in the engine's generated keywords: zu-node, zu-java and zu-c are clean, and zu-python had one false positive that turned out to be DuckDB SQL in a comparison test. Closes #26 * Pick a statement the engine really has not reached The corpus runner has a test saying a case ahead of the engine comes back unsupported rather than failed, which is what lets the corpus be the contract and the engine catch up to it. It used SELECT 1 as the statement no engine had reached yet. The engine parses SELECT now, so the case ran, came back with a column named 1 where the case wanted n, and the test was grading a real failure as though it were a gap. CREATE NODE TABLE person(uid INT64) is the replacement. It refuses with 42001 and the message says CREATE is not implemented yet. A test like this is a canary by construction and the comment now says so: the day CREATE lands, this stops testing what it says it tests and has to pick another spelling. The same assumption was in the Java runner this was ported from and it was fixed there in tamnd/zu-java#20. * the static libraries, built from zu a92d9c1b9c51 --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Follow-up to #19, which went in with CI red on two counts that had nothing to do with the corpus. The corpus itself was right the whole way: 1438 cases, 1438 passed, 0 failed, 0 unsupported against the engine at main.
RunnerTest.aCaseAheadOfTheEngineIsUnsupportedAndNotAFailureusedSELECT 1as a statement the engine has not reached, and the engine reaches it. SELECT is a statement head in ISO 39075 and this engine parses one, so the case came back with a column called1where it wantedn, and the runner correctly called that a failure rather than an unsupported. The statement isCREATE NODE TABLE person(uid INT64)now, which the engine refuses with 42001 and the words "CREATE is not implemented yet, the v0 core is MATCH, WHERE ...". A test like this is a canary by construction and the comment now says so: the day CREATE lands it has to pick another spelling.The javadoc on
Cellsaid{@link #equals}, andCellis a sealed interface that declares noequals, so the reference did not resolve and thereleaseprofile failed the build on it. It points atObject#equals(Object)now, which is the method the records generate an override of and the one the sentence is about. The paragraph is rewrapped around it and nothing else in it changed.The same
SELECT 1assumption is in the Go runner this was ported from, atcorpus/runner_test.go, and it is being fixed there in the change that takes tamnd/zu-go#25 and tamnd/zu-go#26.What was run
On a Linux box against the engine at
55382df, which is main.mvn -pl zudb-corpus -am testis BUILD SUCCESS, withRunnerTest12 of 12 andCorpusTestreporting 25 suites, 1438 cases, 1438 passed, 0 failed, 0 unsupported.mvn -P release -DskipTests package, which is what the javadoc job runs, is BUILD SUCCESS.