Explain the execution flow of submitting a Flink job through StreamPark Console?

Submitting a job from StreamPark Console walks through several distinct stages, most of which are invisible to the user beyond a status change on screen.

Once the job is release-ready, clicking Start triggers Console to load the stored configuration — jar or SQL, execution mode, parallelism, and any connector dependencies — and assemble the equivalent of a Flink submission command internally. Rather than shelling out to a generic script, StreamPark routes this through a dedicated Flink Submit abstraction with an implementation per mode (YARN Session, YARN Application, Kubernetes Session, Kubernetes Application, Remote), so mode-specific parameters are handled correctly.

After submission, StreamPark captures the resulting identifier — a YARN Application ID or a Kubernetes cluster/job ID — and stores it against the job in its own database. From that point on, Console uses this stored ID to poll status, pull logs, and offer actions like savepoint or stop, which is what makes the job feel "managed" rather than merely "launched."