CAMEL-24115: camel-rest-openapi - Write generated operationId back to Operation for dispatch#24781
Conversation
… Operation for dispatch Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Claus Ibsen <claus.ibsen@gmail.com>
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
gnodet
left a comment
There was a problem hiding this comment.
LGTM — clear bug fix for null operationId dispatch.
Verification:
- Confirmed
process()dispatches viaoperation.getOperationId()(lines 203 and 252), resolving todirect:nullwhen the generated ID wasn't written back. - The fix is minimal and correct:
op.setOperationId(id)persists the generated ID so bothvalidateOpenApi()andprocess()use the same value. - The
generateOperationId()method (path sanitization:/→.,{}→_, prefixGENOPID_<VERB>) is unchanged and already well-tested bytestMissingOperationId. - The new test cleanly verifies the write-back: asserts operationIds are null before validation, then checks exact expected values (
GENOPID_GET.users,GENOPID_GET.user._id_) after.
Static analysis: Pre-existing broad-exception-catch warnings only (standard Camel exchange.setException(e) pattern). Nothing introduced by this PR.
Reviewed with Claude Code on behalf of @gnodet. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 18 tested, 29 compile-only — current: 18 all testedMaveniverse Scalpel detected 47 affected modules (current approach: 18).
|
oscerd
left a comment
There was a problem hiding this comment.
LGTM. Real dispatch bug: process() routes to direct: + operation.getOperationId(), but validateOpenApi computed the synthetic id only locally and never persisted it, so at runtime getOperationId() returned null → direct:null. Writing op.setOperationId(id) back unifies validation and dispatch. No shared-spec risk — loadSpecificationFrom parses a fresh OpenAPI per consumer, the swagger Operation is a mutable POJO the consumer owns, and the generated id is deterministic/idempotent. Test asserts null-before / generated-id-after.
Reviewed with Claude Code on behalf of Andrea Cosentino. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.
Summary
Claude Code on behalf of davsclaus
When an OpenAPI spec has operations without
operationId,validateOpenApi()correctly generates synthetic IDs (GENOPID_<VERB><sanitized_path>) and validates against them. However, the generated ID was never written back to theOperationobject, soprocess()calledoperation.getOperationId()which returnednull, dispatching every request todirect:nullinstead of the generated endpoint.Fix: Write the generated operationId back to the
Operationobject invalidateOpenApi(), so both validation and runtime dispatch use the same ID.Failure scenario (before fix):
GET /usersand nooperationIdmissingOperation=fail: startup tells user to adddirect:GENOPID_GET.users; user adds it; validation passes; every request resolvesdirect:null→DirectConsumerNotAvailableException→ HTTP 500missingOperation=mock/ignore: user-defined GENOPID route is silently never invokedTest plan
testMissingOperationIdSetsGeneratedIdOnOperationverifies operationIds are written back after validationtestMissingOperationIdstill passes (validation error message unchanged)camel-rest-openapipass🤖 Generated with Claude Code