oscerd opened a new pull request, #26689:
URL: https://github.com/apache/camel/pull/26689

   # CAMEL-24718: observability must not report a `CamelSqlQuery` header the 
endpoint ignored
   
   ## Problem
   
   CAMEL-24292 (fixVersion 4.23.0) gated the `CamelSqlQuery` header behind the 
new
   `allowQueryFromHeader` option, which is **disabled by default**. When it is 
disabled,
   `SqlProducer` ignores the header and executes the endpoint-configured query 
instead.
   
   Three observability call sites were not updated and still read the header 
unconditionally:
   
   | Module | Site | Symptom |
   |---|---|---|
   | `camel-telemetry` | `SqlSpanDecorator` | `db.statement` span tag |
   | `camel-tracing` (deprecated) | `SqlSpanDecorator` | same tag |
   | `core/camel-console` | `SqlTraceDevConsole` | traced query in the dev 
console |
   
   Under the default configuration all three therefore attribute to the 
exchange **a statement
   that was never executed**, and put sender-controlled text into telemetry — 
an inbound message
   can choose what an operator sees as the executed SQL.
   
   ## Fix
   
   Each site now consults the endpoint's `allowQueryFromHeader` option before 
using the header,
   falling back to the endpoint-configured query.
   
   The option is read through the endpoint's generated `PropertyConfigurer`
   (`Component.getEndpointPropertyConfigurer()` cast to 
`PropertyConfigurerGetter`) rather than by
   casting to a camel-sql type, because none of these three modules may depend 
on `camel-sql`.
   That is a single virtual call plus a string switch on a component-cached 
configurer — deliberately
   chosen over `PropertyConfigurerHelper.resolvePropertyConfigurer`, which 
would perform four
   factory-finder lookups per exchange on a hot path.
   
   An endpoint that does not declare the option at all — `jdbc`, which takes 
its query from the
   message body — never honours the header, which the gate returns correctly.
   
   The gate logic is duplicated as a package-private `SqlQueryHeaderHelper` in 
camel-tracing and
   camel-telemetry because camel-telemetry does not depend on camel-tracing; 
camel-console has its
   own private copy for the same reason.
   
   ## Out of scope
   
   `camel-sql` also ignores the header when `useMessageBodyForSql=true`, 
regardless of
   `allowQueryFromHeader`. Modelling that second condition in three 
observability modules was judged
   not worth the additional coupling; the common default case is what this 
fixes.
   
   ## Backport
   
   **Not needed.** `allowQueryFromHeader` ships in 4.23.0 (unreleased). On 
4.14.x / 4.18.x
   `camel-sql` *always* honours `CamelSqlQuery`, so the decorators reporting it 
there is correct —
   the mismatch only exists from 4.23.0 onward.
   
   ## Tests
   
   - `components/camel-tracing` — `SqlSpanDecoratorTest`, 4 tests (option on / 
option off / endpoint without the option / unknown component)
   - `components/camel-telemetry` — `SqlSpanDecoratorTest`, 4 tests, same matrix
   - `core/camel-console` — new `SqlTraceDevConsoleQueryHeaderTest`, 2 
end-to-end tests driving a stand-in `sql:` component through the event notifier
   
   Both polarities send the *same* header and assert opposite outcomes, so the 
tests fail if the
   option is not actually consulted.
   
   Full suites of all three modules: **470 tests, 0 failures, 0 errors.**
   
   Test style follows each module's existing convention (JUnit assertions — 
these modules are
   0 AssertJ / 24 JUnit), per the project guidance not to mix styles within a 
module.
   
   ## Docs
   
   Extended the existing "camel-sql, camel-sql-stored - the query/template 
override headers are
   gated" section of the 4.23 upgrade guide rather than adding a new one — this 
is the observability
   consequence of the same behaviour change. The dev console is new in 4.23 
(CAMEL-23862), so it
   needs no upgrade note.
   
   ---
   
   _Claude Code on behalf of oscerd_
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


-- 
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]

Reply via email to