Hi all, I’ve still been struggling with this persistent

InvalidPidMappingException

occasionally popping up in some of my Flink jobs that rely on transactions. Typically from the job being down for some period of time (specifically in dev/unmonitored environments), but it has popped up in production environments as well. I’m trying to figure out if there’s a “safe” or better way to handle these as to not crash the job. Typically when these show up, they are either pointing to transactions that were already completed when the job was being brought down during a deployment, or something that has since expired. My question is: is it possible via configuration or some custom support for handling these errors within the KafkaSink to safely ignore these as to not crash the job? I’ve done some cursory searching for specific producer configuration that might suggest that, but I’m also wondering if there’s a means to inject some custom class to the KafkaProducer itself to allow more fine grained control over this? Something like a:

class ExampleHandler(
    override someInterfaceFunctionForErrors(ctx: SomeContext){
         try {
             ctx.executeNormalBehavior()
         }
         catch (ex: InvalidPidMappingException) {
             // Log and ignore
         }
    }
)

along with:

KafkaSink.builder(...)
    ...
    .setKafkaProducerConfig(
        ProducerConfig.SOME_MAGIC_PROPERTY to ExampleHandler::class.java
    )

I don’t think so until the Kafka and Flink improvement proposals on improving 2PC is available

Thanks @Martijn Visser - We’ve encountered this a handful of times and it’s been quite a thorn in our side since we have some jobs that rely on exactly-once processing and these types of transactions typically function as poison pills and I’m not sure if there’s any way around it. As of now it requires restoring the jobs without state which could lead to potential data-loss, which isn’t great either. Just trying to see if there’s any type of workaround that might help in these situations.