[Bug] Message loss caused by returning msgId -1:-1:x after the server turns on deduplication

[zcola]

2025-08-18T10:28:09.779+0800 | DEBUG | [logger/pulsar_log.go:58] Got command! type:SEND_RECEIPT  send_receipt:{producer_id:2  sequence_id:63  message_id:{ledgerId:18446744073709551615  entryId:18446744073709551615}  highest_sequence_id:18446744073709551615} with payload size: 0 maxMsgSize: 11534336 {"remote_addr": "pulsar://7.34ds79:6650", "local_addr": "7.dsds.43:58326"

This message msgId returned -1:-1:x

the server turns on deduplication . version 3.0.4

User feedback on using go coroutines

Occasionally, it occurs, and disabling batch sending does not occur

[intkuroky]

Is it the case that delayed messages and non-delayed messages are mixed in the same producer?

[n24q02m]

Reproduced this on standalone 3.0.11 + master client (a83c151): a harness with 50 concurrent senders over a 45s window (batching on, namespace dedup on, subscription created first) hit a docker restart mid-send — overlap proven by 3 Reconnected producer events — and 50 of 13,049 sends returned -1:-1:0 messageIDs, exactly the symptom in this issue. Pattern: each sender's in-flight message at restart time gets the dup-receipt (e.g. s4 i248, s1 i248, s11 i248). From source: the -1:-1 receipt arrives from the broker on the wire for the exact in-flight sequence (connection.go:765 → producer_partition.go:1418, msgID taken verbatim from the wire receipt), and the client forwards it as a successful Send with nil error, no validation. A second run under the same harness measured the loss dimension: 142,516 sent, 0 dup-receipts, 0 loss (142,516/142,516 unique consumed; 10 consumer redeliveries consistent with at-least-once ack-loss during reconnect) — so the symptom is nondeterministic across restarts, and in the observed case no data was lost, but the caller receives garbage messageIDs as a successful Send. So this does not look fixed broker-side between 3.0.4 → 3.0.11. Happy to share the harness / send a PR-grade repro — could you attach a receipt debug log or goroutine dump from your ops repro? (Working hypothesis, unconfirmed: the trigger is producer-id/sequence reuse across reconnect.)