[FLINK-39730][runtime] Honor maxExceptions on ApplicationExceptionsHandler

[jubins]

What is the purpose of the change

Fixes FLINK-39730 — ApplicationExceptionsHandler does not read the maxExceptions query parameter from the request, and ApplicationExceptionsHeaders is typed on ApplicationMessageParameters (the parent class) rather than ApplicationExceptionsMessageParameters, leaving the latter as orphaned scaffolding from FLINK-38977. As a result, typed Java REST clients setting maxExceptions on the application endpoint had the parameter silently discarded by the server, and downstream clients (e.g. flink-kubernetes-operator) had no way to bound the response size for long-running applications with large exception histories.

This is the follow-up to FLINK-39711 (PR #28202), which exposed the parameter to the typed client API for the job endpoint. Job-side parity already works end-to-end via JobExceptionsHandler; this PR brings the application endpoint to the same behavior.

Brief change log

• Switched ApplicationExceptionsHeaders and ApplicationExceptionsHandler to be typed on ApplicationExceptionsMessageParameters (previously the parent ApplicationMessageParameters), so the dedicated parameters class is finally wired into the handler.
• ApplicationExceptionsHandler.handleRequest now reads UpperLimitExceptionParameter from the request and applies the limit when constructing the response, mirroring JobExceptionsHandler.
• archiveApplicationWithPath uses a MAX_NUMBER_EXCEPTION_TO_REPORT = 20 default when archiving JSON (no client query available at archive time), matching the job-side archive behavior.
• Added an int maxSize argument to ApplicationExceptionsInfoWithHistory.fromApplicationExceptionHistory(...) that limits the rendered history via .limit(maxSize).
• Flipped upperLimitExceptionParameter on ApplicationExceptionsMessageParameters from private final to public final, so callers can resolve it via the typed REST client — mirroring the change made for the job endpoint in FLINK-39711.

Verifying this change

This change is covered by updated unit tests:

• ApplicationExceptionsHandlerTest — new test testMaxExceptionsLimitsHistorySize builds an archived application with 5 exceptions, sets maxExceptions=2 via the typed parameters, and asserts the handler returns exactly 2 entries. Existing tests in the same class were migrated to use ApplicationExceptionsMessageParameters instead of ApplicationMessageParameters to match the handler's new generic type.
• Existing JobExceptionsHandlerTest continues to validate the analogous server-side behavior on the job endpoint, confirming the application change brings the two endpoints into parity.

REST API stability snapshot and generated reference docs were regenerated to reflect the newly-declared maxExceptions query parameter on /applications/:applicationid/exceptions:

• flink-runtime-web/src/test/resources/rest_api_v1.snapshot
• docs/static/generated/rest_v1_dispatcher.yml
• docs/layouts/shortcodes/generated/rest_v1_dispatcher.html

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 — none of ApplicationExceptionsHandler, ApplicationExceptionsHeaders, ApplicationExceptionsMessageParameters, or ApplicationExceptionsInfoWithHistory carries an @Public / @PublicEvolving annotation. The generic-type-parameter switch is technically observable to any caller constructing these classes directly, but they are runtime-internal types not part of Flink's stable user-facing API.
• The serializers: no
• The runtime per-record code paths (performance sensitive): no
• Anything that affects deployment or recovery (JobManager, Checkpointing, Kubernetes/Yarn, ZooKeeper): no
• The S3 file system connector: no

Documentation

• Does this pull request introduce a new feature? yes — the /applications/:applicationid/exceptions endpoint now honors the optional maxExceptions query parameter, consistent with the job-side endpoint.
• If yes, how is the feature documented? Auto-generated REST reference docs (rest_v1_dispatcher.yml / rest_v1_dispatcher.html) — regenerated in this PR alongside the code changes.

Was generative AI tooling used to co-author this PR?

• Yes — Claude was used as a pair-programming assistant for discussing the approach and implementation structure. All code was written, understood, and verified by the author.

Generated-by: Claude Opus 4.7

[flinkbot]

CI report:

• 2783bcc Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

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