Skip to content

Structured gRPC error codes are silently discarded (flight_sql.rs) #181

@thanos

Description

@thanos
  1. Structured gRPC error codes are silently discarded (flight_sql.rs)

Severity: Critical — defeats the structured error design.

FlightSqlServiceClient::{execute, execute_update, prepare, do_get, get_tables, get_db_schemas, get_sql_info} and PreparedStatement::{execute, execute_update} all return
Result<T, ArrowError>. Inside arrow-flight, a tonic Status is converted via status_to_arrow_error(s) → ArrowError::IpcError(format!("{s:?}")). So the gRPC code only
survives as a debug-formatted substring.

The Rust NIF wraps these results into FlightError::Arrow(e) at lines 321, 394, 491, 539, 572, 601, 636, 668, 694. Our flight_error_to_term then matches
FlightError::Arrow(_) → transport_error with grpc_status=0. Result: every server error (:unauthenticated, :permission_denied, :not_found, :invalid_argument,
:unimplemented, :server_error) from a query, DML, prepare, metadata, or prepared-statement call collapses to :transport_error.

Only flight_sql_stream_next preserves codes — because FlightRecordBatchStream internally does status.into() → FlightError::Tonic(...).

The tests don't catch this because they use NIF stubs that emit manually-crafted {code, grpc_status, msg} tuples.

Fix options: parse the "Status { code: ..., message: ...}" debug string out of ArrowError::IpcError back to tonic::Code; or call the lower-level FlightServiceClient
endpoints that return tonic::Status directly; or add a helper like arrow_err_to_term(env, e) that inspects ArrowError::IpcError(msg) for the embedded status.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions