fix(rust/core): add InfoCode::Other to handle arbitrary codes - #4510
Merged
lidavidm merged 1 commit intoJul 22, 2026
Merged
Conversation
`InfoCode` was a closed set of the 11 standard codes, so requests for XDBC-range ([500, 1_000)) or vendor-specific (>= 10_000) info codes could not be represented: the FFI exporter errored on unknown values before the wrapped Rust driver was called, and the JavaScript client dropped them before the driver manager forwarded the request to the loaded driver. A driver could still emit such codes when asked for everything (`info_codes` == `None`), so a vendor code would appear in "fetch all" results but could not be requested explicitly. Add an `InfoCode::Other(u32)` catch-all variant (mirroring the existing `Other` variants on `OptionDatabase`/`OptionConnection`/`OptionStatement`) so codes survive the u32 round-trip, and pass requested codes through unfiltered in both the FFI exporter and the JavaScript client, leaving "ignore unrecognized codes" to the driver as adbc.h states: > Drivers/vendors will ignore requests for unrecognized codes > (the row will be omitted from the result) Signed-off-by: Fredrik Fornwall <fredrik@fornwall.net>
lidavidm
reviewed
Jul 13, 2026
lidavidm
left a comment
lidavidm
left a comment
Member
There was a problem hiding this comment.
Seems reasonable enough. CC @eitsupi @felipecrv too.
Collaborator
|
Looks good, thanks. |
lidavidm
approved these changes
Jul 22, 2026
fornwall
added a commit
to fornwall/adbc-spanner
that referenced
this pull request
Jul 26, 2026
…0ca4b (UP-9) (#394) Moves both validation-suite dependency families to their current upstream `main`, and takes the two behaviour changes that came with them. **apache/arrow-adbc `198f39a9` -> `3b3f123a`** (all three crates plus the C++ suite's ARROW_ADBC_TAG, previously `65957bba`, in lockstep). The one behaviour change in range is apache/arrow-adbc#4510, `InfoCode::Other(u32)`: the FFI exporter used to reject the *whole* `GetInfo` call with "Unknown info code" before the driver ran, so an XDBC-range ([500, 1000)) or vendor-specific (>= 10000) code could never be requested even though "fetch all" could return one. It now forwards them, leaving "ignore unrecognized codes" to the driver as adbc.h states. No driver change was needed — `info::build` already filters explicit requests to `REPORTED` and omits the rest — but the contract was unobservable through the C ABI until now, so pin it from both sides: a unit test at the trait level and an assertion through the driver manager in `conformance_via_driver_manager`. Closes UP-9 in REVIEW.md. apache/arrow-adbc#4534 (the other PR in range worth checking) was already adopted in #343: SqlPrepareUpdate/Stream are un-excluded and gate-enforced with RewriteSql entries pinning the new ORDER BY defaults. `c/validation` has had no commits since, so the tag bump adds no cases, and none of the four survivors in EXCLUDED are reachable by RewriteSql — three are Arrow type-mapping gaps (Duration/Interval/UInt64) and one is an arrow-rs FFI stream limitation (SqlQueryCancel cannot emit ECANCELED). **adbc-drivers/validation `dbc6857f` -> `1c20ca4b`**, which carries adbc-drivers/validation#256: `test_query_bind_dictionary` re-binds the `type/bind/string` and `type/bind/large_string` cases dictionary-encoded — the layout a pandas categorical produces. Both pass unchanged and are gate-enforced (not in the skip baseline, which needed no edit): dictionary encoding is an encoding of the same logical values, not a different logical type, and `bind::cell_value` already decodes the key at each row back through the same mapping as the plain column. Verified: `cargo fmt`/`clippy -D warnings` clean; `with-emulator.sh cargo test` green (321 unit + 53 integration + 44 mock + 6 resilience + 1 doctest); `run-adbc-validation.sh` 89 passed / 7 skipped with the gate, expected-failure and stale guards all OK; `run-foundry-validation.sh` 188 passed / 65 skipped with FOUNDRY_VALIDATION_REQUIRE_PASSES and the skip-baseline guard on. Signed-off-by: Fredrik Fornwall <fredrik@fornwall.net>
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
3 participants
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.
InfoCodewas a closed set of the 11 standard codes, so requests for XDBC-range ([500, 1000)) or vendor-specific (>= 10000) info codes could not be represented: the FFI exporter errored on unknown values before the wrapped Rust driver was called, and the JavaScript client dropped them before the driver manager forwarded the request to the loaded driver.A driver could still emit such codes when asked for everything (
info_codes==None), so a vendor code would appear in "fetch all" results but could not be requested explicitly.Add an
InfoCode::Other(u32)catch-all variant (mirroring the existingOthervariants onOptionDatabase/OptionConnection/OptionStatement) so codes survive the u32 round-trip, and pass requested codes through unfiltered in both the FFI exporter and the JavaScript client, leaving "ignore unrecognized codes" to the driver as adbc.h states: