fix(outbox): stop outboxOpenTelemetryFallback hijacking the real OTEL SDK (#343) #22

Merged

hibryda merged 2 commits from fix/outbox-otel-fallback-no-hijack-343 into main 2026-05-31 23:53:42 +02:00

Conversation 2 Commits 2 Files changed 2 +143 -9

hibryda commented 2026-05-31 23:41:14 +02:00

Owner

Copy link

#343 — stop outboxOpenTelemetryFallback hijacking the real OTEL SDK

Critical pre-existing defect surfaced while verifying #342 (Micrometer→OTLP bridge) live: the 7 outbox services were exporting no telemetry at all — neither metrics nor traces — while error-event-sink (no outbox dependency) exported normally.

Root cause

OutboxAutoConfiguration.outboxOpenTelemetryFallback() returned OpenTelemetry.noop() gated on @ConditionalOnMissingBean alone. The class is @AutoConfigureAfter DataSource/Hibernate/Kafka but not the OpenTelemetry Spring Boot starter's OpenTelemetryAutoConfiguration. Auto-config ordering let the fallback win the race → it registered the no-op SDK → the starter's real OpenTelemetry bean (itself @ConditionalOnMissingBean) backed off → the whole app ran on a no-op OpenTelemetry. Consequences:

• No OTLP export of traces or metrics.
• MicrometerBridgeAutoConfiguration (@ConditionalOnBean(OpenTelemetry.class)) didn't bind → every Micrometer meter (im2be_outbox_*, kafka_consumer_*, jvm_*) fell to the non-exporting SimpleMeterRegistry.

Evidence: user-service condition report — MicrometerBridgeAutoConfiguration Did not match: ... did not find any beans of type io.opentelemetry.api.OpenTelemetry. At the collector :8889, only service_name=error-event-sink produced telemetry.

Fix

Add @ConditionalOnMissingClass("io.opentelemetry.instrumentation.spring.autoconfigure.OpenTelemetryAutoConfiguration") to the fallback bean. Now the decision is order-independent: when the starter is on the classpath (all 8 services) the fallback never registers, so the real SDK always wins. @ConditionalOnMissingBean is retained for the bare-consumer case (app supplies its own OpenTelemetry). The fallback's original purpose — a bare consumer without the starter still boots on no-op — is preserved.

Tests (OutboxOpenTelemetryFallbackTest)

• fallbackProvidesNoopWhenNoOpenTelemetryBeanAndStarterAbsent — bare-consumer path still boots on no-op.
• fallbackYieldsToAUserProvidedOpenTelemetryBean — @ConditionalOnMissingBean behaviour preserved.
• fallbackIsGuardedByConditionalOnMissingClassOfOtelStarter — pins the guard. The OTEL starter is intentionally not a dependency of this library (only opentelemetry-api is), so the classpath-condition's false state can't be exercised in-module; that path is covered by the live post-deploy verification.

mvn -pl outbox-publisher -am install -DskipITs → 106/106 unit, 0 warnings.

Post-merge (operator-gated)

Republish outbox-publisher SNAPSHOT → rebuild the 7 outbox service images --no-cache → re-import → rollout-restart → confirm traces+metrics with service_name in {user,social-login,family,diary,calendar,admin}-service appear at :8889 (not just the sink). Unblocks #342's live close-out + PR-OTEL-9 alerts having data. Memora #3651.

## #343 — stop `outboxOpenTelemetryFallback` hijacking the real OTEL SDK **Critical pre-existing defect** surfaced while verifying #342 (Micrometer→OTLP bridge) live: the 7 outbox services were exporting **no telemetry at all** — neither metrics nor traces — while `error-event-sink` (no outbox dependency) exported normally. ### Root cause `OutboxAutoConfiguration.outboxOpenTelemetryFallback()` returned `OpenTelemetry.noop()` gated on `@ConditionalOnMissingBean` alone. The class is `@AutoConfigureAfter` DataSource/Hibernate/Kafka but **not** the OpenTelemetry Spring Boot starter's `OpenTelemetryAutoConfiguration`. Auto-config ordering let the fallback win the race → it registered the no-op SDK → the starter's **real** `OpenTelemetry` bean (itself `@ConditionalOnMissingBean`) backed off → the whole app ran on a no-op OpenTelemetry. Consequences: - No OTLP export of traces or metrics. - `MicrometerBridgeAutoConfiguration` (`@ConditionalOnBean(OpenTelemetry.class)`) didn't bind → every Micrometer meter (`im2be_outbox_*`, `kafka_consumer_*`, `jvm_*`) fell to the non-exporting `SimpleMeterRegistry`. **Evidence:** user-service condition report — `MicrometerBridgeAutoConfiguration Did not match: ... did not find any beans of type io.opentelemetry.api.OpenTelemetry`. At the collector `:8889`, only `service_name=error-event-sink` produced telemetry. ### Fix Add `@ConditionalOnMissingClass("io.opentelemetry.instrumentation.spring.autoconfigure.OpenTelemetryAutoConfiguration")` to the fallback bean. Now the decision is **order-independent**: when the starter is on the classpath (all 8 services) the fallback never registers, so the real SDK always wins. `@ConditionalOnMissingBean` is retained for the bare-consumer case (app supplies its own `OpenTelemetry`). The fallback's original purpose — a bare consumer *without* the starter still boots on no-op — is preserved. ### Tests (`OutboxOpenTelemetryFallbackTest`) - `fallbackProvidesNoopWhenNoOpenTelemetryBeanAndStarterAbsent` — bare-consumer path still boots on no-op. - `fallbackYieldsToAUserProvidedOpenTelemetryBean` — `@ConditionalOnMissingBean` behaviour preserved. - `fallbackIsGuardedByConditionalOnMissingClassOfOtelStarter` — pins the guard. The OTEL starter is intentionally **not** a dependency of this library (only `opentelemetry-api` is), so the classpath-condition's `false` state can't be exercised in-module; that path is covered by the live post-deploy verification. `mvn -pl outbox-publisher -am install -DskipITs` → **106/106 unit, 0 warnings**. ### Post-merge (operator-gated) Republish `outbox-publisher` SNAPSHOT → rebuild the 7 outbox service images `--no-cache` → re-import → rollout-restart → confirm traces+metrics with `service_name` in {user,social-login,family,diary,calendar,admin}-service appear at `:8889` (not just the sink). Unblocks #342's live close-out + PR-OTEL-9 alerts having data. Memora #3651.

hibryda added 1 commit 2026-05-31 23:41:14 +02:00

fix(outbox): stop outboxOpenTelemetryFallback hijacking the real OTEL SDK (#343) ... ff2fd2f99f

OutboxAutoConfiguration.outboxOpenTelemetryFallback() returned
OpenTelemetry.noop() gated on @ConditionalOnMissingBean alone. This class
is @AutoConfigureAfter DataSource/Hibernate/Kafka but NOT the OpenTelemetry
Spring Boot starter's OpenTelemetryAutoConfiguration, so auto-config
ordering let the fallback win the race: it registered the no-op SDK, and
the starter's real OpenTelemetry bean (itself @ConditionalOnMissingBean)
backed off. Every outbox service then ran on a no-op OpenTelemetry —
silently disabling ALL OTel export (traces + metrics) and preventing the
Micrometer→OTLP bridge (MicrometerBridgeAutoConfiguration,
@ConditionalOnBean(OpenTelemetry.class)) from binding, so Micrometer
meters (im2be_outbox_*, kafka_consumer_*, jvm_*) fell to the
non-exporting SimpleMeterRegistry. Empirically only services WITHOUT the
outbox dependency (error-event-sink) exported telemetry; the 7 outbox
services exported nothing.

Fix: add @ConditionalOnMissingClass for the starter's
OpenTelemetryAutoConfiguration to the fallback bean. The decision is now
order-independent — when the starter is on the classpath (all 8 services)
the fallback never registers, so the real SDK always wins.
@ConditionalOnMissingBean is retained for the bare-consumer case where an
app supplies its own OpenTelemetry bean directly. The fallback's original
purpose (a bare consumer WITHOUT the starter still boots on no-op) is
preserved.

Tests (OutboxOpenTelemetryFallbackTest):
- fallbackProvidesNoopWhenNoOpenTelemetryBeanAndStarterAbsent — bare-consumer path
- fallbackYieldsToAUserProvidedOpenTelemetryBean — @ConditionalOnMissingBean preserved
- fallbackIsGuardedByConditionalOnMissingClassOfOtelStarter — pins the guard
  (the starter is intentionally not a dependency of this lib, so the
  classpath-false state is covered by the live post-deploy verification).

mvn -pl outbox-publisher -am install -DskipITs → 106/106 unit, 0 warnings.

pr-reviewer-bot commented 2026-05-31 23:46:16 +02:00

Member

Copy link

Superseded by round 2.

Show previous round

hib-pr-reviewer review — PR #22 (affinity-intelligence-rework/im2be-platform-libs)

Round 1 — head ff2fd2f99fed, base main, trigger opened

TL;DR: CONDITIONAL_APPROVE — kept 1 agreed finding (A+B on @ConditionalOnMissingClass gap) and 1 verified unique-to-B finding (weak .contains() assertion); no blocking issues.

Summary

Arbitration — PR #22 fix(outbox): stop outboxOpenTelemetryFallback hijacking the real OTEL SDK

Memora: No prior run history found; first arbitration for this PR.

Reconciliation:

• Finding 1 (A+B agreed → KEPT): Both reviewers independently flag @ConditionalOnMissingClass at OutboxAutoConfiguration.java:270–271 as creating a NoSuchBeanDefinitionException startup failure when the OTel starter class is on the classpath but its autoconfiguration is excluded (e.g., via spring.autoconfigure.exclude=...). Read confirmed the annotation is at lines 270–271, and that both outboxPublisher (line 362) and outboxPollerWorker (line 391) inject OpenTelemetry as a non-optional required parameter — no ObjectProvider wrapper. Before this PR, @ConditionalOnMissingBean would have correctly filled the gap; the new guard regresses that scenario.

• Finding 2 (Unique to B → VERIFIED + KEPT): Read confirmed line 90–92 of the test uses .contains(...) not .containsExactly(...). The assertion passes as long as the target class name appears somewhere in the String[] annotation value; extra entries added in a future refactor would silently evade the regression guard. Verification confirms B's claim is accurate.

Memora: Run 1 summary persisted (memory id 467).

Blast Radius

The diff touches one auto-configuration class and one new test class within a single outbox-publisher module. The @ConditionalOnMissingClass change affects every service that carries the outbox dependency alongside the OTel Spring Boot starter — a real but bounded surface. No public API or protocol contracts are modified.

BLAST_SCORE: 3/10

CI status (head ff2fd2f99fed)

Overall: ✓ success

2 checks: 2 pending

Check	State	Link
im2be-platform-libs CI / mvn install (pull_request)	⏳ pending	details
im2be-platform-libs CI / mvn verify (main only) (pull_request)	⏳ pending	details

Findings (2)

[MINOR] @ConditionalOnMissingClass introduces a NoSuchBeanDefinitionException when the OTel starter is on the classpath but its autoconfiguration is excluded

outbox-publisher/src/main/java/com/aim2be/platform/outbox/OutboxAutoConfiguration.java:270

The new guard is a classpath check, not a bean-presence check. When opentelemetry-spring-boot-starter is a transitive dependency but the application explicitly excludes its autoconfiguration (e.g., spring.autoconfigure.exclude=io.opentelemetry.instrumentation.spring.autoconfigure.OpenTelemetryAutoConfiguration): (1) the class IS on the classpath → @ConditionalOnMissingClass evaluates to false → the fallback does not register; (2) the starter's OpenTelemetryAutoConfiguration is excluded → no real OpenTelemetry bean is registered either; (3) both outboxPublisher (line 362) and outboxPollerWorker (line 391) take final OpenTelemetry openTelemetry as a required (non-ObjectProvider) parameter → context startup fails with NoSuchBeanDefinitionException. Before this PR, @ConditionalOnMissingBean alone correctly covered this scenario by registering the noop fallback.

Preferred fix: Replace the per-method @ConditionalOnMissingClass guard with a class-level @AutoConfigureAfter(name = "io.opentelemetry.instrumentation.spring.autoconfigure.OpenTelemetryAutoConfiguration") and keep only @ConditionalOnMissingBean on the method. When the starter is active, ordering guarantees the real bean exists before the fallback is evaluated; when the starter is absent or excluded, @ConditionalOnMissingBean registers the noop as before — covering all three deployment paths without the gap.

If the classpath guard is retained: Document the known limitation in the Javadoc and inject OpenTelemetry via ObjectProvider<OpenTelemetry> in the affected beans, or add a dedicated @ConditionalOnMissingBean fallback that applies even when the class is present but excluded.

[MINOR] Annotation-pin assertion uses .contains() instead of .containsExactly(), allowing silent annotation bloat to go undetected

outbox-publisher/src/test/java/com/aim2be/platform/outbox/OutboxOpenTelemetryFallbackTest.java:90

At line 90–92, assertThat(guard.value()).contains("io.opentelemetry...") only verifies that the target class name is somewhere in the String[] value of @ConditionalOnMissingClass. If a future refactor adds a second class name to the annotation (e.g., to guard an additional starter version), the test still passes while the annotation contract has silently drifted and the extra guard may suppress the fallback in unintended scenarios.

Replace with:

assertThat(guard.value())
    .as("the guard must name exactly the OpenTelemetry Spring Boot starter auto-config")
    .containsExactly(
        "io.opentelemetry.instrumentation.spring.autoconfigure.OpenTelemetryAutoConfiguration");

This pins both the content and the count of guarded class names, which is the point of a regression-guard test.

Verdict

CONDITIONAL_APPROVE

---

_{hib-pr-reviewer • round 1 • 2 findings (2m) • 2026-05-31T21:44:58.159Z → 2026-05-31T21:46:16.452Z • posted-as: pr-reviewer-bot • model: auto}

<!-- hib-pr-reviewer collapsed --> > _Superseded by round 2._ <details> <summary>Show previous round</summary> <!-- hib-pr-reviewer round:1 --> ## hib-pr-reviewer review — PR #22 (affinity-intelligence-rework/im2be-platform-libs) **Round 1** — head `ff2fd2f99fed`, base `main`, trigger `opened` **TL;DR:** CONDITIONAL_APPROVE — kept 1 agreed finding (A+B on @ConditionalOnMissingClass gap) and 1 verified unique-to-B finding (weak .contains() assertion); no blocking issues. ### Summary ## Arbitration — PR #22 `fix(outbox): stop outboxOpenTelemetryFallback hijacking the real OTEL SDK` **Memora:** No prior run history found; first arbitration for this PR. **Reconciliation:** - **Finding 1 (A+B agreed → KEPT):** Both reviewers independently flag `@ConditionalOnMissingClass` at `OutboxAutoConfiguration.java:270–271` as creating a `NoSuchBeanDefinitionException` startup failure when the OTel starter class is on the classpath but its autoconfiguration is excluded (e.g., via `spring.autoconfigure.exclude=...`). Read confirmed the annotation is at lines 270–271, and that both `outboxPublisher` (line 362) and `outboxPollerWorker` (line 391) inject `OpenTelemetry` as a non-optional required parameter — no `ObjectProvider` wrapper. Before this PR, `@ConditionalOnMissingBean` would have correctly filled the gap; the new guard regresses that scenario. - **Finding 2 (Unique to B → VERIFIED + KEPT):** Read confirmed line 90–92 of the test uses `.contains(...)` not `.containsExactly(...)`. The assertion passes as long as the target class name appears _somewhere_ in the `String[]` annotation value; extra entries added in a future refactor would silently evade the regression guard. Verification confirms B's claim is accurate. **Memora:** Run 1 summary persisted (memory id 467). ### Blast Radius The diff touches one auto-configuration class and one new test class within a single `outbox-publisher` module. The `@ConditionalOnMissingClass` change affects every service that carries the outbox dependency alongside the OTel Spring Boot starter — a real but bounded surface. No public API or protocol contracts are modified. **BLAST_SCORE: 3/10** ### CI status (head `ff2fd2f99fed`) **Overall: ✓ success** 2 checks: 2 pending | Check | State | Link | |---|---|---| | im2be-platform-libs CI / mvn install (pull_request) | ⏳ pending | [details](/affinity-intelligence-rework/im2be-platform-libs/actions/runs/114/jobs/0) | | im2be-platform-libs CI / mvn verify (main only) (pull_request) | ⏳ pending | [details](/affinity-intelligence-rework/im2be-platform-libs/actions/runs/114/jobs/1) | ### Findings (2) #### **[MINOR]** `@ConditionalOnMissingClass` introduces a `NoSuchBeanDefinitionException` when the OTel starter is on the classpath but its autoconfiguration is excluded _outbox-publisher/src/main/java/com/aim2be/platform/outbox/OutboxAutoConfiguration.java:270_ The new guard is a classpath check, not a bean-presence check. When `opentelemetry-spring-boot-starter` is a transitive dependency but the application explicitly excludes its autoconfiguration (e.g., `spring.autoconfigure.exclude=io.opentelemetry.instrumentation.spring.autoconfigure.OpenTelemetryAutoConfiguration`): (1) the class IS on the classpath → `@ConditionalOnMissingClass` evaluates to `false` → the fallback does not register; (2) the starter's `OpenTelemetryAutoConfiguration` is excluded → no real `OpenTelemetry` bean is registered either; (3) both `outboxPublisher` (line 362) and `outboxPollerWorker` (line 391) take `final OpenTelemetry openTelemetry` as a required (non-`ObjectProvider`) parameter → context startup fails with `NoSuchBeanDefinitionException`. Before this PR, `@ConditionalOnMissingBean` alone correctly covered this scenario by registering the noop fallback. **Preferred fix:** Replace the per-method `@ConditionalOnMissingClass` guard with a class-level `@AutoConfigureAfter(name = "io.opentelemetry.instrumentation.spring.autoconfigure.OpenTelemetryAutoConfiguration")` and keep only `@ConditionalOnMissingBean` on the method. When the starter is active, ordering guarantees the real bean exists before the fallback is evaluated; when the starter is absent or excluded, `@ConditionalOnMissingBean` registers the noop as before — covering all three deployment paths without the gap. **If the classpath guard is retained:** Document the known limitation in the Javadoc and inject `OpenTelemetry` via `ObjectProvider<OpenTelemetry>` in the affected beans, or add a dedicated `@ConditionalOnMissingBean` fallback that applies even when the class is present but excluded. #### **[MINOR]** Annotation-pin assertion uses `.contains()` instead of `.containsExactly()`, allowing silent annotation bloat to go undetected _outbox-publisher/src/test/java/com/aim2be/platform/outbox/OutboxOpenTelemetryFallbackTest.java:90_ At line 90–92, `assertThat(guard.value()).contains("io.opentelemetry...")` only verifies that the target class name is _somewhere_ in the `String[]` value of `@ConditionalOnMissingClass`. If a future refactor adds a second class name to the annotation (e.g., to guard an additional starter version), the test still passes while the annotation contract has silently drifted and the extra guard may suppress the fallback in unintended scenarios. Replace with: ```java assertThat(guard.value()) .as("the guard must name exactly the OpenTelemetry Spring Boot starter auto-config") .containsExactly( "io.opentelemetry.instrumentation.spring.autoconfigure.OpenTelemetryAutoConfiguration"); ``` This pins both the content and the count of guarded class names, which is the point of a regression-guard test. ### Verdict **CONDITIONAL_APPROVE** --- _{hib-pr-reviewer • round 1 • 2 findings (2m) • 2026-05-31T21:44:58.159Z → 2026-05-31T21:46:16.452Z • posted-as: pr-reviewer-bot • model: auto} </details>

hibryda added 1 commit 2026-05-31 23:49:28 +02:00

fix(outbox): order outbox after OTEL starter instead of classpath guard (#343 R1) ... e7bd62ffdd

R1 CONDITIONAL_APPROVE findings (kept=2, both MINOR, no blockers):

(1) MINOR OutboxAutoConfiguration.java — the @ConditionalOnMissingClass
    guard has a gap: when opentelemetry-spring-boot-starter is on the
    classpath but its OpenTelemetryAutoConfiguration is excluded
    (spring.autoconfigure.exclude), the class-present check skips the
    fallback AND no real OpenTelemetry bean exists → outboxPublisher /
    outboxPollerWorker (required, non-ObjectProvider OpenTelemetry params)
    fail with NoSuchBeanDefinitionException. The classpath guard mishandles
    the present-but-excluded path.
(2) MINOR OutboxOpenTelemetryFallbackTest.java:90 — the annotation-pin used
    .contains() not .containsExactly(), so a stray added guard name would
    pass undetected.

Fix (adopted the reviewer's preferred solution — strictly better):
- Replaced the per-method @ConditionalOnMissingClass with a class-level
  @AutoConfigureAfter(name="...OpenTelemetryAutoConfiguration") (by name —
  the starter is not a dependency of this lib) and kept only
  @ConditionalOnMissingBean on the bean. Ordering guarantees the real SDK
  bean is registered before the fallback's @ConditionalOnMissingBean is
  evaluated → real bean wins when present; @ConditionalOnMissingBean
  registers the no-op when the starter is absent OR excluded. Covers all
  three paths (present / absent / present-but-excluded) without a startup
  failure.
- Test: the guard now asserts the class-level @AutoConfigureAfter.name()
  containsExactly the OTEL starter FQN (pins content + count).

Verification:
- mvn -pl outbox-publisher -am install -DskipITs → 106/106 unit, 0 warnings
- mvn -pl outbox-publisher clean compile test-compile → 0 [WARNING]

pr-reviewer-bot commented 2026-05-31 23:51:22 +02:00

Member

Copy link

hib-pr-reviewer review — PR #22 (affinity-intelligence-rework/im2be-platform-libs)

Round 2 — head e7bd62ffdd88, base main, trigger synchronize

TL;DR: NO_NEW_FINDINGS — No new findings this round.

Summary

[quorum-converged] A=0 = B=0. Both R1 findings are addressed cleanly:

1. R1 @ConditionalOnMissingClass hazard — the code does not use @ConditionalOnMissingClass. The chosen fix (@AutoConfigureAfter(name = "…OpenTelemetryAutoConfiguration")) correctly covers all three deployment paths (absent / present / present-but-excluded) without a NoSuchBeanDefinitionException. The Javadoc at lines 270–276 explicitly documents why the class-only guard would be wrong, satisfying the R1 concern.

2. R1 .contains() → .containsExactly() — OutboxOpenTelemetryFallbackTest.java:100 now uses .containsExactly(...). The inline comment at lines 92–93 explicitly cites #22 R1, confirming the intent.

The @AutoConfigureAfter(value = {...}, name = "...") split is idiomatic Spring Boot autoconfiguration (both attributes are honoured during ordering resolution). The isSameAs(OpenTelemetry.noop()) reference-equality check is valid because the OTel API returns the same singleton instance from noop(). The ApplicationContextRunner setup provides all required beans (OutboxRecordRepository, DataSource, KafkaProperties) and outboxMetricsBinder consumes MeterRegistry via ObjectProvider, so absence of a registry does not fail startup. No new actionable issues found.

CI status (head e7bd62ffdd88)

Overall: ⏳ pending

2 checks: 2 pending

Check	State	Link
im2be-platform-libs CI / mvn verify (main only) (pull_request)	⏳ pending	details
im2be-platform-libs CI / mvn install (pull_request)	⏳ pending	details

Findings

No new findings this round.

Quorum converged on empty findings (A + B both returned 0).

Verdict

NO_NEW_FINDINGS

---

_{hib-pr-reviewer • round 2 • 0 findings • 2026-05-31T21:49:30.161Z → 2026-05-31T21:51:21.847Z • posted-as: pr-reviewer-bot • model: auto • [bookkeeping fallback]}

<!-- hib-pr-reviewer round:2 --> ## hib-pr-reviewer review — PR #22 (affinity-intelligence-rework/im2be-platform-libs) **Round 2** — head `e7bd62ffdd88`, base `main`, trigger `synchronize` **TL;DR:** NO_NEW_FINDINGS — No new findings this round. ### Summary [quorum-converged] A=0 = B=0. Both R1 findings are addressed cleanly: 1. **R1 `@ConditionalOnMissingClass` hazard** — the code does not use `@ConditionalOnMissingClass`. The chosen fix (`@AutoConfigureAfter(name = "…OpenTelemetryAutoConfiguration")`) correctly covers all three deployment paths (absent / present / present-but-excluded) without a `NoSuchBeanDefinitionException`. The Javadoc at lines 270–276 explicitly documents why the class-only guard would be wrong, satisfying the R1 concern. 2. **R1 `.contains()` → `.containsExactly()`** — `OutboxOpenTelemetryFallbackTest.java:100` now uses `.containsExactly(...)`. The inline comment at lines 92–93 explicitly cites `#22 R1`, confirming the intent. The `@AutoConfigureAfter(value = {...}, name = "...")` split is idiomatic Spring Boot autoconfiguration (both attributes are honoured during ordering resolution). The `isSameAs(OpenTelemetry.noop())` reference-equality check is valid because the OTel API returns the same singleton instance from `noop()`. The `ApplicationContextRunner` setup provides all required beans (`OutboxRecordRepository`, `DataSource`, `KafkaProperties`) and `outboxMetricsBinder` consumes `MeterRegistry` via `ObjectProvider`, so absence of a registry does not fail startup. No new actionable issues found. ### CI status (head `e7bd62ffdd88`) **Overall: ⏳ pending** 2 checks: 2 pending | Check | State | Link | |---|---|---| | im2be-platform-libs CI / mvn verify (main only) (pull_request) | ⏳ pending | [details](/affinity-intelligence-rework/im2be-platform-libs/actions/runs/115/jobs/1) | | im2be-platform-libs CI / mvn install (pull_request) | ⏳ pending | [details](/affinity-intelligence-rework/im2be-platform-libs/actions/runs/115/jobs/0) | ### Findings **No new findings this round.** _Quorum converged on empty findings (A + B both returned 0)._ ### Verdict **NO_NEW_FINDINGS** --- _{hib-pr-reviewer • round 2 • 0 findings • 2026-05-31T21:49:30.161Z → 2026-05-31T21:51:21.847Z • posted-as: pr-reviewer-bot • model: auto • [bookkeeping fallback]}

hibryda merged commit 5d1f12f1a3 into main 2026-05-31 23:53:42 +02:00

hibryda deleted branch fix/outbox-otel-fallback-no-hijack-343 2026-05-31 23:53:42 +02:00

hibryda referenced this pull request from a commit 2026-05-31 23:53:42 +02:00

fix(outbox): stop outboxOpenTelemetryFallback hijacking the real OTEL SDK (#343) (#22)

hibryda referenced this pull request from a commit 2026-05-31 23:57:38 +02:00

fix(apicurio): order schema-registry after OTEL starter — same noop hijack (#343)

hibryda referenced this pull request 2026-05-31 23:57:54 +02:00

fix(apicurio): order schema-registry after OTEL starter — same noop hijack (#343) #23

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

affinity-intelligence-rework/im2be-platform-libs!22

No description provided.