Kafka Transactional IdDistributed Systems & Databases

Human baseline3h

TaxonomyDistributed Systems & DatabasesDistributed Systems & Databases

Task prompt

# Kafka Exactly-Once Payment Duplication A Kafka-based payment processing pipeline, deployed as a replicated Kubernetes workload, has started producing duplicate records in the downstream accounting database after a Kubernetes migration. - Duplication rate: ~0.02% (about 200 duplicates per million payments) - Started three weeks ago, coinciding with a Kubernetes migration - Pipeline ran correctly for six months before the migration - Kafka broker logs are clean - Producer EOS configuration appears correct Fix the pipeline so that a 1-hour production run at 10,000 messages/second with pod restarts every 60 seconds produces zero duplicate payment records in the accounting database while maintaining throughput >= 9,500 msg/sec. Do not change the following exactly-once semantics configuration: - Producer: `enable.idempotence=true`, `acks=all` - Consumer: `isolation.level=read_committed` Do not mask the problem with additional deduplication or duplicate suppression layers. The duplicates must be prevented at the source. Your `fixed_producer.py` artifact will be evaluated as a standalone Python file; it must not depend on other files under `/app`. Write the following artifacts to `/logs/artifacts/`: 1. `fixed_producer.py` — the corrected, self-contained producer 2. `consumer.py` — a copy of the unchanged consumer 3. `simulation_result.json` — result of running `/app/simulation.py` against `fixed_producer.py` 4. `root_cause.txt` — a brief explanation of the root cause and the fix

What it tests

The bug is invisible to Kafka configuration audits and broker logs. The identity resolution is abstracted into a separate `platform_identity.py` module that is documented as the stable, platform-provided replica identity. The operational runbook reinforces the false sense of safety by listing standard EOS checks that all pass and suggesting migration-related operational hypotheses (network topology, persistent volume remounts, consumer rebalances) that point away from the real issue. The actual defect is that the module returns the pod's hostname/pod name, which is randomized by the Kubernetes Deployment on every restart. The agent must cross-check the runbook against the Deployment manifest in `/app/k8s/` and the identity module's implementation, then produce a self-contained `fixed_producer.py` that uses a stable per-replica source such as `POD_ORDINAL`. This combines adversarial trust signals with cross-file reasoning, requiring the solver to reason globally rather than patch a single obvious line. The scenario is synthetic but grounded in a realistic production incident pattern: hostname-derived transactional.id values are a known failure mode after Kubernetes migrations, and the resulting ~0.02% duplicate rate is representative of what teams observe when epoch fencing breaks. In a real organization this task would be performed by a senior backend engineer, SRE, or Kafka platform engineer responding to a payment duplication incident after an infrastructure migration.