Function init_producer_id_identity_decision 

pub fn init_producer_id_identity_decision(
    entry_pid: i64,
    entry_epoch: i16,
    last_epoch: i16,
    prev_pid: i64,
    request_pid: i64,
    request_epoch: i16,
) -> InitProducerIdIdentityDecision

What an InitProducerId caller’s producer identity may do to the entry it names (KIP-360).

A request producer id of -1 supplies no identity, which every InitProducerId below v3 and every first initialisation does.

Kafka admits a supplied identity in TransactionCoordinator’s isValidProducerId: the identity names the entry’s producer id, whatever its epoch, or it names the producer id from before the last rotation together with an exhausted epoch. The epoch then decides the outcome in TransactionMetadata.prepareIncrementProducerEpoch: the entry’s own epoch bumps it, the epoch before the last bump is a retry of that bump, and every other epoch is fenced.

The retry rule also covers a failed epoch fence: that path records the epoch the producer still holds as the last epoch, so the producer that owns the transaction is the one the rule admits.

Kafka’s isValidProducerId has a third admission clause, which this kernel does not model: txnMetadata.producerEpoch == RecordBatch.NO_PRODUCER_EPOCH admits every supplied identity, and prepareIncrementProducerEpoch then bumps. Only the metadata that handleInitProducerId has just created for an unknown transactional ID carries that epoch. The host covers the clause: it answers a transactional ID with no entry by allocating a fresh identity without calling this kernel, and every entry it does pass here has a nonnegative epoch, because allocation hands out nonnegative epochs and crate::transaction::transaction_pid_install_decision rejects a replayed entry with a negative current or staged epoch.