Skip to content

v0.37.0 — conformance validator no longer rejects zero-parameter calls

Choose a tag to compare

View all tags
@rustyconover rustyconover released this 04 Aug 23:46
· 205 commits to main since this release
v0.37.0
821c8d4

🔧 Fix: the conformance validator rejected zero-parameter calls

If v0.36.1 failed your port on methods that take no arguments, the validator was wrong and your port was right. Upgrade.

v0.36.1 added round-trip validation of request_data and required every request batch to carry exactly one row. The wire format does not: a row is required only when the schema has fields, because a method with no parameters has nothing to put in one. From _wire.py:

if len(batch.schema) > 0 and batch.num_rows != 1:
    raise RpcError("ProtocolError", ...)

The conformance service's own void_noop sends an empty schema — no columns, no rows. So the validator rejected the reference implementation's own output, and any port that matched it. A correct Java port was reported non-conformant.

Why it shipped

vgi-rpc-conformance — the reference worker other ports are compared against — had no --access-log flag. Other ports could be driven through vgi-rpc-test --access-log and validated; Python could not. The one implementation that defines correct behaviour was the only one that could never be run through its own validator.

Compounding it: request_data appears only at DEBUG. The existing end-to-end test ran a fixture worker at INFO, where the field is absent — so it validated records in which the rule under discussion had nothing to act on. The checking that did happen was manual.

Both holes are now closed.

New: the reference can validate itself

vgi-rpc-conformance --access-log /tmp/a.log --access-log-debug

--access-log-debug raises the access channel to DEBUG, which is the only level that emits request_data.

New: --require-request-data

vgi-rpc-test --cmd "./your-worker --access-log /tmp/log --access-log-debug" \
             --access-log /tmp/log \
             --require-request-data

The schema lets a record opt out of request_data by declaring truncated, which every emitter does at INFO. So a validator that only checks well-formed when present is satisfied by a log that never carries the field at all — the same shape as asserting a CORS expose list without ever asserting the header. The rule holds everywhere except where it applies.

--require-request-data makes an absent field a failure on unary records.

For porters

Add this to CI, not to a checklist:

do why
Run the worker's access log at DEBUG request_data is absent at INFO, so every rule about it goes unexercised
Pass --require-request-data otherwise a log that never emits the field passes
Include a zero-parameter method (void*) in the filter that is the case this release fixes
Run it in CI this drifted precisely because verification was manual

The reference now does exactly this in its own test suite, driving the shipped vgi-rpc-conformance worker through vgi-rpc-test and asserting that void_* records carry valid request_data.

See the porting guide's How to verify section.

Upgrading: no action required for library users — this is conformance tooling. Ports validating against 0.36.1 should upgrade and re-run; failures on zero-parameter methods will clear.

Assets 2
Loading