Overall, I'm +1 on the idea. The only thing that I'm not fully decided on is the fact that the job submission would be blocking on the remote download. We could immdiately return the submission call and have the job in `INITIALIZING` state, if everything is ok, it would transition into CREATED, RUNNING, etc. If not, it would go into FAILED, and clients would have to fetch the error from the job's exception endpoint.
It will make client implementations more difficult .. but the kubernetes operator is anyways polling already, so that should be fine. A long time ago, I worked on https://issues.apache.org/jira/browse/FLINK-16866. Where a low `web.timeout` caused issues with slow job submissions. Can you check if your proposed implementation and defaults work well in the case where the remote artifact fetching for session clusters is stalling indefinetly? Will we see the right error message on the client ("artifact fetching timed out") instead of ("job submission timed out")? On Mon, Aug 24, 2026 at 12:41 AM Dale Lane <[email protected]> wrote: > I'd like to start a discussion on > FLIP-XXX : Remote Artifact Fetch for Session-Mode Job Submission > > https://docs.google.com/document/d/1drZkXU875-j7lsyJaLp-VkVG_1PRietlfO2ETLeEWJc/edit?usp=sharing > > This FLIP proposes extending Flink's existing remote-artifact-fetch > capability to session-mode job submission, so that a job can be submitted > by URI, with the Job Manager performing the fetch itself, the same way an > Application Mode cluster already does at start-up. > > Looking forward to discussion - please let me know what you think! > > Kind regards > > Dale > -- > dalelane.co.uk > >
