How do you troubleshoot duplicate rows appearing when using Dynamic Bucket mode with multiple concurrent write jobs?

Dynamic Bucket mode relies on an internal index mapping each primary key to the bucket it belongs in, so that all records for a given key are routed consistently to the same bucket regardless of when they arrive. That guarantee assumes a single logical writer path is responsible for assigning and honoring that index for a given key range.

1. Check for multiple independent write jobs. Running more than one separate streaming/batch job writing into the same Dynamic Bucket table concurrently is the most common root cause — each job can end up making independent bucket-assignment decisions for the same key, leading to the same key landing in two different buckets and surviving as two "different" rows after merge.
2. Consolidate into a single writer path. Route all upserts for a table through one job (or one coordinated set of tasks that share the bucket-assignment index) rather than multiple independent jobs targeting the same table.
3. Verify checkpointing/restart behavior. A job that restarted without properly resuming from its last consistent checkpoint can also reprocess records in a way that confuses bucket assignment; confirm checkpoint recovery is configured correctly.
4. Consider Fixed Bucket if writer topology can't be consolidated. Fixed Bucket's hash-based assignment doesn't depend on a shared runtime index, so it tolerates multiple independent writers more predictably, at the cost of losing Dynamic Bucket's automatic scaling.
5. Inspect $files and $snapshots. Look at which buckets and snapshots introduced the duplicate key to confirm which writer path caused it, before deciding whether to consolidate jobs or switch bucket modes.