Hi Zhe, You are right, and the status table promised a 404 the endpoint cannot decide on its own. I've split it by who can know: Flink answers 404 for the cases it can observe, and a coordinator that does not serve these requests says so with a RestHandlerException carrying NOT_FOUND. IllegalArgumentException is now only for a payload the coordinator does serve and finds wrong. Flink's own two coordinators will do the same; the compatibility section says what that changes on the internal route.
Both cases you asked about are named in the test plan now, with a unit test for each of Flink's own coordinators. Thanks, Yunfeng Zhou > 2026年11月2日 13:26，Zhe Wang <[email protected]> 写道： > > Hi Yunfeng, > > Thanks for narrowing the scope. Reusing the existing coordinator request > path makes sense to me. > > I have one question about the 404 contract for coordinators that do not > accept external requests. `DefaultOperatorCoordinatorHandler` currently > only checks whether the coordinator implements > `CoordinationRequestHandler`. For example, `CollectSinkOperatorCoordinator` > implements that interface but rejects anything other than > `CollectCoordinationRequest` with `Preconditions.checkArgument`. With the > proposed `IllegalArgumentException` mapping, an external request reaching > it would appear to produce 400 rather than 404. > > Is 404 intended only for coordinators without `CoordinationRequestHandler`, > or also for those that implement it but do not support > `ExternalCoordinationRequest`? Could the integration tests explicitly cover > an internal-only coordinator alongside an external-capable coordinator > rejecting an invalid payload, so this distinction is clear? > > Best, > Zhe Wang > > > Yunfeng Zhou <[email protected]> 于2026年10月18日周日 20:58写道： > >> Hi Gen, >> >> You were right, and I've narrowed FLIP-617 the way you suggested — to an >> externally accessible coordinator handler. It delivers one opaque JSON >> payload >> to the addressed operator's coordinator and returns the coordinator's >> answer. >> >> Your point about the bridge is what the design rests on: rather than an >> SPI that >> needs a bridge handed to it, the endpoint reuses the delivery path Flink >> already >> has. Why the general SPI was dropped is written up under "Rejected >> Alternatives". >> >> The page has been retitled and rewritten for the narrowed scope: >> https://cwiki.apache.org/confluence/x/C6rwGg >> >> Thanks, >> Yunfeng Zhou >> >> On 2026/10/14 03:43:56 Gen Luo wrote: >>> Hi Yunfeng, >>> >>> Thanks for this proposal. It's helpful to be able to customize REST >>> handlers, so >>> developers can easily expose a service of their own that accesses their >>> plugin >>> components running in the JobManager or inside a Flink job, like some RPC >>> operator >>> service. >>> >>> However, I suppose that accessing a plugin needs a bridge from the REST >>> handler to >>> the internal component/service, but the bridge to the component itself is >>> not >>> included in this proposal, and we don't exactly know what bridge is >> needed. >>> At this >>> point, I think OperatorCoordinator is the most widely used plugin >>> component, which >>> does have the bridge. Other pluggable components like ShuffleService are >>> rarely >>> customized and also lack the bridge. In conclusion, for components >> without >>> such a >>> bridge, to implement a customized REST service, patches on Flink are >> still >>> needed, >>> so the proposal itself may only cover a narrow scene like >>> OperatorCoordinator. >>> >>> Can you share the aiming scene and reevaluate whether we need a fully >>> pluggable REST >>> handler, or a specific handler that is needed? If you indeed need a >> service >>> that >>> accesses an OperatorCoordinator, maybe we can narrow down the proposal >> to an >>> externally accessible coordinator handler. >>> >>> On Sat, Oct 10, 2026 at 4:16 PM Yunfeng Zhou <[email protected]> wrote: >>> >>>> Hi all, >>>> >>>> I'd like to start a discussion on FLIP-617: Support Pluggable REST >> Handler >>>> Extensions. >>>> >>>> Currently, Flink's JobManager exposes a REST endpoint as the >> control-plane >>>> entry point for cluster and job operations, but adding a new REST >> operation >>>> requires registering it inside Flink core. For components that are >>>> developed and released separately from Flink, this leaves only two >>>> unattractive options: maintain a Flink fork, or add component-specific >> APIs >>>> to Flink core and couple the component's release cycle to Flink's. >> Flink >>>> already offers extension mechanisms for areas such as file systems, >>>> metrics, and security, but the REST endpoint has no general mechanism >> for a >>>> component to contribute its own routes. >>>> >>>> This FLIP proposes a pluggable, cluster-level extension mechanism that >>>> lets a trusted component register its own JobManager REST routes, >> reusing >>>> Flink's existing REST routing, versioning, leader retrieval, and >> lifecycle, >>>> while keeping the component's REST resources and runtime semantics >> outside >>>> Flink core. The mechanism is intended to be experimental and additive, >> and >>>> to leave the behavior of existing REST endpoints unchanged. >>>> >>>> FLIP page: >>>> https://cwiki.apache.org/confluence/x/C6rwGg >>>> >>>> Feedback on any part is welcome. >>>> >>>> Thanks, >>>> Yunfeng Zhou >>>
