Confluent-kafka-dotnet: Invalid offset [-1001] on produce async

[jake0029]

Description

Received invalid offset -1001on ProduceAsync but consumer receives the message.
During sint and uat, my consumer did not receive any messages when producer responded invalid offset [-1001] . This is my first time to successfully receive message from kafka even failed during producing message.

Hope you can help me with this issue.

Does -1001 invalid offset means successful on produce or failed?

Checklist

Please provide the following information:

• [0.11.6 ] Confluent.Kafka nuget version.
• [ Apache 2.0] Apache Kafka version.
• [ ] Client configuration.
  var producerConfig = new Dictionary {
  { "bootstrap.servers", nkafka1:9093,nkafka2:9093,nkafka3:9093 },
  { "default.topic.config", new Dictionary()
  {
  { "acks", "all" },
  { "message.timeout.ms",5000 }
  }
  },
  { "message.send.max.retries", 0 },
  { "security.protocol", "SSL" },
  { "ssl.ca.location", "C:\Windows\ssl\ca-root.crt" }
  };
• [Windows 2008 R2] Operating system.
• [n/a] Provide logs (with "debug" : "..." as necessary in configuration).
• [Financial lost] Critical issue.

[mhowlett]

It means you don't know - it seems a problem occurred that meant the broker could not respond to the client about the delivery of the message before the produce call timed out. this is a fundamental limitation.

you can get better semantics by enabling idempotent producer + by using the upcoming transactions capability.

[jake0029]

But as per checking -1001 invalid offset message is same with when kafka is unavailable, does it mean -1001 invalid offset response is the same with request time out and kafka unavailable

[tomasdeml]

We have observed a _positive/success_ delivery result with Offset == -1001 for a Task<DeliveryResult> ProduceAsync() call in our application (at least it seems like it). Is that really possible? I would expect an exception when the client does not receive an ACK from the broker.

(Confluent.Kafka v1.3.0, Acks.All, EnableIdempotence=true, EnableDeliveryReports=true)

[edenhill]

This can happen with the idempotent producer for implicitly acked messages, i.e., if batch 1 is successfully acked, batch 2's ack is lost due to e.g. request timeout, but batch 3 is acked it means that batch 2 is implicitly acked through batch 3's ack, but the offsets of the batch 2 is not known.

This scenario should be pretty rare though, if your cluster and network is healthy.

[tomasdeml]

Just of curiosity, could you point me to any documentation, design or KIP document mentioning this behavior? My Google-fu is not so strong today...

[edenhill]

https://docs.google.com/document/d/11Jqy_GjUGtdXJK94XGsEIK7CP1SnQGdp2eF0wSw9ra8/edit

(linked from KIP-98)