fix(rust/ffi): ignore unrecognized info codes in get_info instead of erroring - #27
Closed
fornwall wants to merge 1 commit into
Closed
fix(rust/ffi): ignore unrecognized info codes in get_info instead of erroring#27fornwall wants to merge 1 commit into
fornwall wants to merge 1 commit into
Conversation
fornwall
force-pushed
the
fix/get-info-ignore-unrecognized-codes
branch
5 times, most recently
from
July 13, 2026 22:43
d7a285d to
c8f87fb
Compare
`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>
fornwall
force-pushed
the
fix/get-info-ignore-unrecognized-codes
branch
from
July 13, 2026 22:45
c8f87fb to
97999a4
Compare
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.
Problem
The ADBC spec is explicit about unrecognized
get_infocodes (adbc.h):The C++ SQLite reference driver does exactly that — its
InfoImplswitch has adefault: // Ignorearm.The Rust FFI exporter, however, collected the caller's raw
u32codes into aResult<HashSet<InfoCode>>and ran it throughcheck_err!, so the first code that didn't map to a knownInfoCodefailed the wholeAdbcConnectionGetInfocall withADBC_STATUS_INVALID_DATA— zero rows returned, including for the valid codes in the same request. That contradicts both the spec and the C reference driver.This isn't observable through the high-level
driver_managerAPI (it only ever sends knownInfoCodes), only from a raw C-ABI caller — e.g. a driver-manager in another language passing a code this Rust enum doesn't yet know.Fix
In
connection_get_info, drop codes that don't parse (filter_map(|c| InfoCode::try_from(*c).ok())) instead of erroring, so unrecognized codes are silently omitted and the recognized ones are still answered — matching the spec and the SQLite driver.InfoCode::try_from's only error is the unknown-code case, so.ok()discards exactly the intended set.Test
Added
test_connection_get_info_ignores_unrecognized_codesto the dummy exporter integration test. Like the existingtest_statement_execute_query_sets_rows_affected, it drives the C ABI directly (the driver manager can't send an unknown code through its typed API), passing a valid code alongsideu32::MAXand assertingADBC_STATUS_OK.cargo fmt --check,cargo clippy -p adbc_ffi, and the dummy integration test all pass.