Hello Jason, thanks for the great write-up. 0. One question about the migration plan: "The new GetTransactionState API and the new version of the transaction state message will not be used until the inter-broker version supports it." I'm not so clear about the implementation details here: say a broker is on the newer version and the txn-coordinator is still on older version. Today the APIVersionsRequest can only help upgrade / downgrade the request version, but not forbidding sending any. Are you suggesting we add additional logic on the broker side to handle the case of "not sending the request"? If yes my concern is that this will be some tech-debt code that will live long before being removed.
Some additional minor comments: 1. "last epoch" and "instance epoch" seem to be referring to the same thing in your wiki. 2. "The broker must verify after receiving the response that the producer state is still unknown.": not sure why we have to validate? If the metadata returned from the txn-coordinator can always be considered the source-of-truth, can't we just bindly use it to update the cache? Guozhang On Thu, Sep 6, 2018 at 9:10 PM Matthias J. Sax <matth...@confluent.io> wrote: > I am +1 on this :) > > > -Matthias > > On 9/4/18 9:55 AM, Jason Gustafson wrote: > > Bump. Thanks to Magnus for noticing that I forgot to link to the KIP: > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-360%3A+Improve+handling+of+unknown+producer > > . > > > > -Jason > > > > On Tue, Aug 21, 2018 at 4:37 PM, Jason Gustafson <ja...@confluent.io> > wrote: > > > >> Hi All, > >> > >> I have a proposal to improve the transactional/idempotent producer's > >> handling of the UNKNOWN_PRODUCER error, which is the result of losing > >> producer state following segment removal. The current behavior is both > >> complex and limited. Please take a look and let me know what you think. > >> > >> Thanks in advance to Matthias Sax for feedback on the initial draft. > >> > >> -Jason > >> > > > > -- -- Guozhang
