davsclaus commented on PR #26843:
URL: https://github.com/apache/camel/pull/26843#issuecomment-5812860748
A correction to my own justification above, before this is merged.
I claimed this one mistake produced 2580 runtime failures. It did appear
that many times in the benchmark logs, but **the path parameter resolves
correctly** — I tested it end to end rather than only reading the code:
```
POST /api/stock/CAMEL-MUG/reserve HTTP/1.1
```
That is `rest-openapi` with `operationId: reserveStock` against a spec whose
path is `/stock/{sku}/reserve`, with `sku` set as a header.
`RestOpenApiEndpoint.resolveUri` leaves `{sku}` for the `rest:` endpoint it
builds, and `RestProducer.resolvePlaceholders` substitutes it from the header.
There is no defect in that path.
The 2580 came from a model's *intermediate* route versions during its edit
loop: `camel-run.out` accumulates across every dev-mode reload within an
example, so a broken draft keeps logging until the file is fixed. I counted
transient authoring states as one systemic failure, which is not what they are.
So the honest case for this change is narrower than the PR body says: when a
placeholder genuinely has no value — which happens while authoring, and to
anyone who forgets the header — the request goes out with `{name}` in the path
and the 404 explains nothing. The warning says which parameter it was. It does
not fix a broken component, because the component is not broken.
I am leaving the change as it stands (warn only, behaviour unchanged, 7563
camel-core tests green), but the record should say what it actually is. Happy
to close it instead if you would rather not carry a diagnostic-only warning.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
