What Does This Do

Fix intermittent Hystrix observable test timeouts while retaining RxJava 1.0.7 coverage and enabling strict trace writes in both observable test suites.

Why the tests were failing

RxJava 1.0.7 has a race in observeOn error handling that can leave its worker spinning inside OperatorObserveOn.pollQueue().

The error is stored as a notification in the same queue as ordinary values. The following interleaving can occur:

1. The worker enters the normal queue-draining path.
2. The producer publishes an error.
3. The worker consumes and delivers that error through the normal path, which does not return after delivering a terminal notification.
4. On the next iteration, the worker enters the error-draining path and searches for the error notification it already consumed.

This explains the seemingly contradictory symptoms: Hystrix delivers its fallback and the spans finish, but the asynchronous task never returns.

The task’s tracing scope consequently remains open, retaining its continuation. Strict trace writes wait for that continuation to be released, and the trace assertion eventually times out.

sequenceDiagram
    participant P as Producer
    participant W as RxJava worker
    participant H as Hystrix
    participant T as Trace lifecycle

    W->>W: Enter normal drain path
    P->>W: Enqueue error notification
    W->>H: Consume and deliver error
    H->>H: Execute fallback and finish spans
    W->>W: Enter error path
    loop Error notification already consumed
        W->>W: Poll queue
    end
    Note over W,T: Task never returns. scope and continuation remain open
    T->>T: Strict trace assertion times out

The continuation diagnostic exposed the unfinished task; it was not itself causing the failure. An agent-free reproducer exhibited the same loop on RxJava 1.0.7. Replacing first() with single() also reproduced the hang, so merely waiting for downstream completion was insufficient.

What changed

For the baseline error-producing fixtures, transport the error across the scheduler as an ordinary notification:

source.materialize()
  .observeOn(scheduler)
  .dematerialize()

materialize() converts the error into a value, avoiding the broken observeOn error-draining path. dematerialize() restores the error on the scheduler thread before Hystrix receives it.

Coverage tradeoff

The baseline fixtures still run against RxJava 1.0.7, but deliberately avoid its defective native error-draining path. Direct-path coverage remains in the latest-dependency suite.

This avoids upgrading away from the baseline version, weakening trace assertions, or adding production instrumentation to repair an upstream library bug.

Motivation

Additional Notes

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors
• Once approved, use merge queue to merge the PR

Jira ticket: [PROJ-IDENT]