CAMEL-24113: Fix rest-openapi producer cross-contamination for same operation#24803
Conversation
…rameters, and producerComponentName in delegate rest: endpoint URI to prevent cross-contamination between routes targeting the same operation 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
gnodet
left a comment
There was a problem hiding this comment.
Claude Code on behalf of gnodet
Review — CAMEL-24113: Fix rest-openapi producer cross-contamination for same operation
Well-analyzed bug fix. The endpoint cache key (componentEndpointUri) previously only included host, so two rest-openapi endpoints targeting the same operation with different produces, consumes, queryParameters, or producerComponentName shared one cached RestEndpoint — the last configureProperties() call silently overwrote the first's settings.
The fix
Including all distinguishing options in the delegate URI so each unique combination gets its own cached endpoint. Verified the coverage:
| Parameter | In URI key? | Notes |
|---|---|---|
host |
✅ | Was already there (only one before) |
producerComponentName |
✅ | New |
consumes |
✅ | New |
produces |
✅ | New |
queryParameters |
✅ | New, URL-encoded. Includes resolved literal values (via literalQueryParameterValue) |
I initially wondered whether queryParameters would just be a template from the spec (same for both endpoints), but traced through queryParameter() → literalQueryParameterValue(): when this.parameters contains the param name, it resolves to name=encodedLiteralValue rather than name={name}. So the URI key correctly differentiates literal-value variants. ✅
The UnsafeUriCharactersEncoder.encode() on queryParameters is correct since it may contain = and & characters. ✅
Tests
Both tests use real DefaultCamelContext (started/stopped in try-finally) and verify:
shouldNotCrossContaminateProducersForSameOperation— differentproduces→ 2 distinct delegate endpoints with correct media types ✅shouldNotCrossContaminateQueryParameters— different literal query param values → 2 distinct delegate endpoints with correct resolved values ✅
Both use AssertJ assertions per project conventions. ✅
LGTM — nice companion fix to #24802.
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 18 tested, 29 compile-only — current: 19 all testedMaveniverse Scalpel detected 47 affected modules (current approach: 19).
|
2 participants
Summary
Claude Code on behalf of davsclaus
RestOpenApiEndpoint.createProducerFor()to includeproduces,consumes,queryParameters, andproducerComponentNamein the delegaterest:endpoint URI, so each unique combination gets its own cached endpointhostwas included in the URI cache key, causing two rest-openapi endpoints targeting the same operation (same HTTP method + base path + URI template + host) to share one cachedRestEndpointsingleton — the lastconfigureProperties()call silently overwrote the first's configurationproducesvalues and differentqueryParametersvalues produce distinct delegate endpointsTest plan
RestOpenApiEndpointV3TestpassshouldNotCrossContaminateProducersForSameOperationverifies two endpoints with differentproducesget distinct delegate endpointsshouldNotCrossContaminateQueryParametersverifies two endpoints with different literal query parameter values get distinct delegate endpoints🤖 Generated with Claude Code
Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com