Hi Gyula, Here is a very basic sketch of a possible fix https://github.com/apache/flink/compare/master...fghibellini:flink:delayed-cleanup?expand=1
I haven't wired up a new configuration option yet as *I first wanted to get some feedback on whether this approach seems reasonable*. The basic idea is to leverage the existing 2-step global cleanup logic. 1. A dirty record is created. This signals that the resources stored in distributed storage are being cleaned up. Each resource might still be available or may already be deleted. 2. Only after all resources are cleaned up is the dirty record removed, which signifies that the job is fully cleaned up. Crucially, after step 1 the job clearly advertises that it shall not be executed again but it is still loaded from disk at startup (and reported by the web API). This fix delays the actual cleanup of resources by a configurable time interval after the dirty record is created. This results in a minimally invasive changeset while achieving exactly what was desired: a reliable period during which the job's termination is reported. I intend to spend some more time considering this changeset's consequences and testing it in our staging environment before creating a full-fledged PR. Any feedback is welcome. Thanks Filippo On Thu, 23 Jul 2026 at 15:06, Gyula Fóra <[email protected]> wrote: > Hey Filippo! > > You are on a pretty outdated version of the operator, I would try to > reproduce on the latest release (1.15) or even better on the current main. > Tickets like this that relate to old versions of the operator are often not > picked up (sometimes already fixed) > > If it's still broken, you can attempt to fix yourself and open a PR and we > can definitely help review. > > Unfortunately there isn't a dedicated dev team here that monitors all > tickets :/ > > Cheers > Gyula > > On Thu, Jul 23, 2026 at 2:15 PM Filippo Ghibellini < > [email protected]> wrote: > > > (cross-posted from user@ mailing list due to lack of activity) > > > > Hello, > > > > Four weeks ago we created the following Jira issue FLINK-39989 but there > > has been no reaction so far. > > > > https://issues.apache.org/jira/browse/FLINK-39989 > > > > In the issue we described the steps to reproduce a reconciliation failure > > in the Flink Kubernetes Operator. This failure arises if the job manager > > terminates before the operator has a chance to learn about the job's > > termination. > > > > My understanding is that as long as the operator requires observing a > job's > > termination for correct operation, a finished job must be restored on a > > job manager's startup (which is currently not the case). > > > > We would be happy to contribute this change if we can get some guidance > > from the dev team. > > > > Thanks, > > Filippo > > >
