Verdict: flaky test / CI infrastructure, not caused by PR #7619 — medium confidence.

What failed

Adapter Tests / Test Adapters (gke-runners-amd64, ...) in a merge-queue run for #7619:
https://github.com/feldera/feldera/actions/runs/40375093325/job/121764995826

connector_suites (static connectors, transport::kafka::ft::test::random_end_to_end_json_array_small) failed:

thread '<unnamed>' panicked at crates/connectors/src/transport/kafka/ft/test.rs:2437:21:
proptest_kafka_end_to_end_json_array_small: error: error on input endpoint 'test_input1': UnknownPartition (Local: Unknown partition)

which then caused the check_end_to_end wait (crates/connectors/src/test/kafka.rs:418) to time out and panic with called Result::unwrap() on an Err value: ().

The job's RSS logger shows memory doubling right around the failure (685 MiB → 1.21 GiB → 1.92 GiB in ~2s), consistent with CI resource pressure rather than a logic bug.

Why I don't think the PR caused it

• crates/connectors/src/transport/kafka/ft/input.rs and crates/connectors/src/test/kafka.rs (topic creation / UnknownPartition handling, retry/backoff logic) are unchanged in substance by Engine-independent adapters #7619 — the diff there is only #[cfg(test)] → #[cfg(any(test, feature = "testing"))] and a couple of unrelated renames.
• random_end_to_end_json_array_small itself (and check_end_to_end) is pre-existing logic, just moved into the new static-connectors test harness.
• Every other recent main merge-queue run in the last ~30 (gh run list --workflow ci.yml) has Adapter Tests passing.
• This PR's two prior merge-queue attempts (runs 40369343699, 40352769190) each failed on a different, unrelated job (Rust Unit Tests, Build Rust Binaries respectively), suggesting general CI flakiness under this PR's unusually large diff rather than a failure specific to this code path.

Related flaky-Kafka-FT-test issues (same suite, different tests)

• Flaky test: transport::kafka::ft::test::test_kafka_metadata_raw #6430 test_kafka_metadata_raw
• Flaky tests: exchange::tests::multihost and kafka ft test_input_partitions_latest #6728 test_input_partitions_latest

None of those match this test/error exactly, so opening separately rather than commenting there.

Next step

If this recurs on other PRs (not just large ones), worth checking whether the Redpanda service container is resource-starved when many Adapter Tests runs happen concurrently on gke-runners-amd64, and whether check_topics's per-topic fetch_watermarks retry (crates/connectors/src/test/kafka.rs:45-67) needs to also cover the consumer thread's own metadata fetch, not just the admin client's.