fix(operator-api): log the specific failure in dora_read_data instead… - #3246
fix(operator-api): log the specific failure in dora_read_data instead…#3246GuTS805 wants to merge 1 commit into
Conversation
… of silently returning None Three unrelated failure modes (input already consumed, malformed Arrow FFI schema, non-UInt8 payload type) collapsed into an indistinguishable None with zero diagnostics. The equivalent C node-API function (read_dora_input_data) already logs the failing Arrow type via tracing::error! - this brings the operator-side twin to parity. A C/C++ operator receiving a routine non-byte input from an upstream Rust/Python node (not a corner case - every other FFI accessor in the C/C++ surface already handles and logs this, tracked as dora-rs#2030) got a silent empty payload with no way to tell apart 'input was empty', 'already read this input', 'type mismatch', or 'malformed FFI schema'. Documented as a known-but-unfiled Medium finding in the internal 2026-06-04 soundness audit; the sibling leak in examples/c-dataflow/operator.c was already fixed separately, but this diagnostics gap was not. Rebased onto current upstream main (was accidentally branched off a 206-commits-stale fork main) and adapted to the DoraArray/ internal::from_array_data rename from dora-rs#3213.
|
Merging to
After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here |
|
Reviewed the diff. The refactor from the The two added tests assert on real behavior ( No issues found. 🤖 Fully automated review by Claude (Claude Code) — no human in the loop. Advisory only; please verify before acting. Generated by Claude Code |
Three unrelated failure modes (input already consumed, malformed Arrow FFI schema, non-UInt8 payload type) collapsed into an indistinguishable None with zero diagnostics. The equivalent C node-API function (read_dora_input_data) already logs the failing Arrow type via tracing::error! - this brings the operator-side twin to parity.
A C/C++ operator receiving a routine non-byte input from an upstream Rust/Python node (not a corner case - every other FFI accessor in the C/C++ surface already handles and logs this, tracked as #2030) got a silent empty payload with no way to tell apart 'input was empty', 'already read this input', 'type mismatch', or 'malformed FFI schema'.
Documented as a known-but-unfiled Medium finding in the internal 2026-06-04 soundness audit; the sibling leak in examples/c-dataflow/operator.c was already fixed separately, but this diagnostics gap was not.
Rebased onto current upstream main (was accidentally branched off a 206-commits-stale fork main) and adapted to the DoraArray/internal::from_array_data rename from #3213.