Two Rust benches cannot link, so they can never run; the CI gate only type-checks them

Comece reproduzindo as falhas com cargo bench --manifest-path fraiseql_rs/Cargo.toml --all-features --bench memory -- --test e com o comando equivalente do pipeline. Leia fraiseql_rs/Cargo.toml, benches/memory.rs, benches/pipeline.rs e a etapa de CI adicionada por #500. Considera-se concluído quando o escopo escolhido estiver resolvido e ambos os benches forem executados com sucesso ou removidos, com a CI verificando os targets resultantes.

Found while verifying what remained actionable in #491. #500 fixed the bench compile errors and added a CI step that keeps them compiling, which holds — but "compiling" here means cargo check, and cargo check does not link. Two of the seven benches cannot produce an executable at all.

What happens

Each bench built individually, --all-features, on b85762dee:

connection_pool     builds
core_benchmark      builds
memory              LINK FAILS
mutation_benchmark  builds
pipeline            LINK FAILS
query_execution     builds
streaming           builds

cargo bench --manifest-path fraiseql_rs/Cargo.toml --all-features --bench memory -- --test:

mold: error: undefined symbol: PyUnicode_FromStringAndSize
mold: error: undefined symbol: PyEval_RestoreThread
mold: error: undefined symbol: _Py_Dealloc
  >>> referenced 52 more times
clang: error: linker command failed with exit code 1
error: could not compile `fraiseql_rs` (bench "memory")

The five that build do run — cargo bench --bench core_benchmark -- --test reports Testing components/byte_reader_parsing … Success.

Why

Both failing benches, and only those two, call into the PyO3-dependent half of the crate:

// fraiseql_rs/benches/memory.rs:2, fraiseql_rs/benches/pipeline.rs:3
use fraiseql_rs::pipeline::builder::build_graphql_response;

pyo3 is declared with extension-module unconditionally (fraiseql_rs/Cargo.toml:62), which tells it not to link libpython — the interpreter resolves those symbols at import time. Any target that produces an executable and actually references them therefore cannot link. It is the same constraint the comment above the CI build step already records for cargo test. There is no feature combination that avoids it: extension-module is on the dependency line, not behind a feature.

The other five link because nothing they call reaches a Python symbol.

Why CI does not catch it

The gate added by #500 is:

- name: Check all targets (benches and test binaries)
  run: cargo check --manifest-path fraiseql_rs/Cargo.toml --all-targets --all-features

cargo check stops after type-checking, so it validates that these two benches still match the API they call — the #471 drift problem, which it does solve — while never discovering that they cannot be executed. Adding --all-targets to the neighbouring cargo build step does not work either; that is exactly what #491 proposed, and it fails on memory, pipeline and the lib test target.

Scope

Both benches are declared with harness = false in Cargo.toml, so they are meant to be run. As things stand they are dead weight of the same kind as the test directories removed in #506: present, type-checked, and unrunnable.

Worth deciding rather than assuming: remove them, or move build_graphql_response behind a boundary the benches can call without dragging in PyO3. The second is only worth it if the pipeline builder is genuinely something we want benchmarked, which is a performance question, not a build one.

Credit to @Joemon24, whose #491 was pulling on this same thread — the benches not really being built — and whose PR is what prompted the check.