[FLINK-31931] Return 404 for a gone TaskManager and stop the Web UI from re-polling it

[MartijnVisser]

What is the purpose of the change

Requesting /taskmanagers/:taskmanagerid for a TaskManager that is no longer registered (for example after a TaskManager is lost while the Web UI's TaskManager page keeps polling it, or when following a link from a job's exception history) returned HTTP 500 with an Unhandled exception ERROR log on the JobManager, and the Web UI kept re-requesting it indefinitely.

This returns a proper 404 for a gone TaskManager and stops the futile polling, showing a clear "TaskManager not available" notice instead of an endless skeleton.

This supersedes #22542 (thanks @JunRuiLee for the original investigation). That PR addressed FLINK-31931 by preventing the exception-history page from linking to a gone TaskManager. Handling the not-found at the destination instead is more robust: it also covers deep-links and a TaskManager dying while its page is open, it is not racy (a TaskManager can disappear right after the link is rendered), and it keeps the link informative for the common case where the exception's TaskManager is already gone by the time the history is viewed.

Brief change log

• [runtime/rest] TaskManagerDetailsHandler strips the failure with stripCompletionException (not stripExecutionException), so the UnknownTaskExecutorException to NOT_FOUND mapping actually fires; this matches the sibling TaskManager handlers. Previously a gone TaskManager produced a 500 plus a repeated Unhandled exception ERROR log.
• [runtime-web] loadManager no longer swallows errors; a shared poll helper stops polling once the backend reports the TaskManager is gone (404), while transient errors keep retrying. The TaskManager status view shows a "TaskManager not available" notice and the metric cards are hidden instead of rendering blank tables.

Verifying this change

• New unit test TaskManagerDetailsHandlerTest#testUnknownTaskExecutorLeadsToNotFound asserts a 404 for an unknown TaskManager id.
• New Vitest specs cover the poll helper (stops on 404, keeps retrying on transient errors) and the status/metrics components (notice shown / cards hidden on 404).
• Manually verified on a standalone cluster: killing a TaskManager now yields a single 404 that stops repeating, a "TaskManager not available" notice, and no Unhandled exception ERROR log on the JobManager, versus the previous endless 500s.

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): no
• The public API, i.e., is any changed class annotated with @Public(Evolving): no
• The serializers: no
• The runtime per-record code paths (performance sensitive): no
• Anything that affects deployment or recovery: no
• The S3 file system connector: no

Documentation

• Does this pull request introduce a new feature? no
• If yes, how is the feature documented? not applicable

AI Usage Disclosure

• Claude Code

[flinkbot]

CI report:

• fde2d9e Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[spuru9]

@MartijnVisser Can you add before and after images to the PR.

[doguscan-namal]

Is "410 Gone" a better response code here if we knew the TaskManager was there but is gone and this is permanent? https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/410

Otherwise, 404 default should be fine.

[MartijnVisser]

Is "410 Gone" a better response code here if we knew the TaskManager was there but is gone and this is permanent?

Good question. I'd keep 404 here. The status comes from mapping UnknownTaskExecutorException, which fires whenever the id isn't in the currently-registered set: we can't actually distinguish "was here, now gone" from "never existed" (a stale/deep-link with a bogus id hits the same path). It also keeps this handler consistent with the sibling TaskManager handlers (log list, profiling list, file handlers), which all map UnknownTaskExecutorException to NOT_FOUND; that consistency is exactly what this PR is fixing.