Concrete R2DBC/r2dbc-proxy example showing the factory-hook +
AssignReturned + wrap-helper + listener shape, so the existing
"check for an interception SPI" guidance is operationalizable, not
just prose.

Adds tracing for R2DBC (reactive database access) by installing an
official r2dbc-proxy ProxyMethodExecutionListener instead of hand-writing
advice on Statement.execute()/Batch.execute(). The listener owns the
reactive lifecycle (complete/error/cancel) so spans can't leak on
cancellation, which a hand-rolled Publisher wrapper is prone to since
reactive pipelines cancel constantly (take(1), timeouts, driver-level
DiscardOnCancel).

- R2dbcInstrumentation hooks ConnectionFactories.find(ConnectionFactoryOptions)
  via @Advice.AssignReturned-style exit advice and wraps the returned
  ConnectionFactory with r2dbc-proxy.
- TraceProxyExecutionListener implements ProxyMethodExecutionListener,
  starting/finishing spans in beforeQuery/afterQuery.
- R2dbcConnectionCallbackInstrumentation + R2dbcSqlCommentInjector add
  DBM SQL comment injection, mirroring JDBC's SQLCommenter.
- r2dbc-proxy is declared implementation (not compileOnly) and its full
  class set is listed in helperClassNames() in dependency order: ordinary
  R2DBC apps don't depend on r2dbc-proxy, so its classes must be injected
  into the app's classloader (and added to the muzzle validation
  classpath via extraDependency) or the module is blocked/fails to load
  at runtime despite passing build-time checks.

Verified via a live trace comparison against the OpenTelemetry Java
agent on a Spring WebFlux + R2DBC/PostgreSQL sample app: matching
INSERT/CREATE TABLE/error-SELECT spans with correct DBM tags
(db.instance, db.type, db.user, peer.hostname, _dd.dbm_trace_injected).

R2dbcConnectionCallbackInstrumentation listed ConnectionCallbackHandler
in its own helperClassNames() — that class is this module's
instrumentedType(), so ByteBuddy already defines it on the target
classloader. Listing it as a helper injects a second, redundant
definition of the class currently being transformed.

r2dbc-proxy is bundled as a real dependency, so its own
ConnectionFactoryProvider (DRIVER="proxy") is discoverable by
ConnectionFactories.find() alongside real drivers. If an application
requests that URL scheme directly, find() already returns an
r2dbc-proxy-wrapped factory; wrapping it again would double the query
listener callbacks and produce duplicate spans. Skip wrapping in that
case — this means apps using DRIVER="proxy" directly get no DD spans,
which is preferable to silently duplicating them.

extractDbType returned DRIVER unconditionally. For pooled URLs like
r2dbc:pool:postgresql://..., DRIVER is the wrapper's own name ("pool"),
losing the real database type. Prefer PROTOCOL only when DRIVER is a
known wrapper (currently "pool") — other drivers legitimately use the
driver:protocol URL shape for their own sub-mode designator (e.g.
r2dbc:h2:mem:///..., where DRIVER="h2" is already the real type and
PROTOCOL="mem" must not override it).

…atches

Several interlocking fixes to the DBM/resource-name path:

- Helper-injection bug: ConnectionCallbackHandler (and BatchCallbackHandler)
  were listed as helper classes in the other r2dbc modules. Helper-injected
  classes are loaded untransformed, so the createStatement/add advice that
  injects the DBM comment never actually ran — the _dd.dbm_trace_injected tag
  only appeared because it was set unconditionally. Removed both instrumented
  types from every helper list so their advice is applied.

- _dd.dbm_trace_injected is now set only when the executed query actually
  carries a DD comment (SharedDBCommenter.containsTraceComment), instead of
  unconditionally on every query.

- Statement-creation-time injection no longer embeds a per-execution
  traceparent (it referenced the ambient span, not the query span, which does
  not exist yet). It injects only static connection metadata, matching JDBC's
  prepareStatement path; the tag reflects that.

- Resource name goes through DBQueryInfo/SQLNormalizer (literals stripped),
  with any injected DBM comment stripped first so it doesn't leak into it.

- Batch#add(String) is now instrumented (R2dbcBatchCallbackInstrumentation),
  so batched statements get DBM comments too.

- Connection metadata is held in a WeakHashMap keyed by ConnectionInfo, so
  entries are evicted when the connection is unreachable rather than relying
  on a close() callback that abrupt disconnects never fire.

Tests updated for normalized resource names and comment-aware assertions.

The bundled r2dbc-proxy requires Reactor at runtime (e.g.
DelegatingContextView implements reactor.util.context.ContextView), but
the R2DBC SPI itself only requires Reactive Streams. On an R2DBC app
without reactor-core, injecting those proxy helper classes would fail and
leave the factory uninstrumented. Guard all three modules with a
classLoaderMatcher on reactor.core.publisher.Flux so instrumentation only
applies when Reactor is available.

The repo reserves Java/JUnit for unit tests and requires Groovy/Spock for
instrumentation tests (AGENTS.md). Port all three r2dbc instrumentation
test classes to Spock specs under src/test/groovy, preserving every test
and assertion (span shape, normalized resource names, DBM tag/comment
behavior, peer.service, error tags). No production changes.

The listener-SPI guidance told authors to declare the interception
library compileOnly and inject its classes via helperClassNames(). That
does not work: a compileOnly dependency is absent from the agent jar, so
there is nothing to inject and both build-time muzzle and runtime helper
definition fail. Correct it to use implementation scope (bundled into the
agent), and note that bundling pulls in transitive deps (guard on their
presence with classLoaderMatcher) and that the full transitive class set
must be listed in topological order.

…Spock"

This reverts commit 551ab66.

A review comment asked to move the tests to Groovy/Spock, but the repo's
"Enforce Groovy migration" CI check rejects any new .groovy file — the
project has migrated to JUnit 5 for instrumentation tests (see
docs/how_to_test_with_junit.md). Keep the tests as Java/JUnit, which is
the current convention. The resource-name normalization and DBM
assertion updates remain (they were made before the port).

…per execution and suitable for caching

JDBC's DBMCompatibleConnectionInstrumentation always appends the comment
for SQL Server at prepareStatement; createStatement is R2DBC's equivalent.
r2dbc-mssql registers the drivers "sqlserver" and "mssql".

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Besides take(1), check spans still finish when a query is cancelled via
next(), blockFirst() and Mono.from(...) (the shape behind Spring
DatabaseClient's first()).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

…260904