Long.parseLong Error with Redis Client Instrumentation

[iqnev]

Describe the bug

I recently upgraded my application to Quarkus 3.15.2, and since then, I've encountered a NumberFormatException related to OpenTelemetry and Redis client instrumentation that wasn't happening prior to the upgrade. And the issue arises specifically when the app is shutting down or cleaning up resources.

java.lang.NumberFormatException: Cannot parse null string
    at java.base@21.0.3/java.lang.Long.parseLong(Long.java:672)
    at java.base@21.0.3/java.lang.Long.parseLong(Long.java:832)
    at io.quarkus.opentelemetry.runtime.tracing.intrumentation.vertx.RedisClientInstrumenterVertxTracer$CommandTrace.dbIndex(RedisClientInstrumenterVertxTracer.java:127)
    at io.quarkus.opentelemetry.runtime.tracing.intrumentation.vertx.RedisClientInstrumenterVertxTracer$RedisClientAttributesExtractor.onStart(RedisClientInstrumenterVertxTracer.java:171)
    at io.quarkus.opentelemetry.runtime.tracing.intrumentation.vertx.RedisClientInstrumenterVertxTracer$RedisClientAttributesExtractor.onStart(RedisClientInstrumenterVertxTracer.java:165)
    at io.opentelemetry.instrumentation.api.instrumenter.Instrumenter.doStart(Instrumenter.java:176)
    at io.opentelemetry.instrumentation.api.instrumenter.Instrumenter.start(Instrumenter.java:129)
    at io.quarkus.opentelemetry.runtime.tracing.intrumentation.vertx.InstrumenterVertxTracer.sendRequest(InstrumenterVertxTracer.java:98)
    at io.quarkus.opentelemetry.runtime.tracing.intrumentation.vertx.RedisClientInstrumenterVertxTracer.sendRequest(RedisClientInstrumenterVertxTracer.java:63)
    at io.quarkus.opentelemetry.runtime.tracing.intrumentation.vertx.RedisClientInstrumenterVertxTracer.sendRequest(RedisClientInstrumenterVertxTracer.java:25)
    at io.quarkus.opentelemetry.runtime.tracing.intrumentation.vertx.OpenTelemetryVertxTracer.sendRequest(OpenTelemetryVertxTracer.java:60)
    at io.quarkus.opentelemetry.runtime.tracing.intrumentation.vertx.OpenTelemetryVertxTracer.sendRequest(OpenTelemetryVertxTracer.java:16)
    at io.quarkus.opentelemetry.runtime.tracing.intrumentation.vertx.OpenTelemetryVertxTracingFactory$VertxDelegator.sendRequest(OpenTelemetryVertxTracingFactory.java:98)
    at io.vertx.redis.client.impl.CommandReporter.before(CommandReporter.java:94)
    at io.vertx.redis.client.impl.PooledRedisConnection.send(PooledRedisConnection.java:74)
    at io.quarkus.redis.runtime.client.ObservableRedis$ObservableRedisConnection.send(ObservableRedis.java:141)
    at io.vertx.redis.client.impl.RedisAPIImpl.send(RedisAPIImpl.java:59)
    at io.vertx.redis.client.RedisAPI.unsubscribe(RedisAPI.java:6540)
    at io.vertx.mutiny.redis.client.RedisAPI.lambda$unsubscribe$1017(RedisAPI.java:14456)
    at io.smallrye.context.impl.wrappers.SlowContextualConsumer.accept(SlowContextualConsumer.java:21)
    at io.smallrye.mutiny.vertx.AsyncResultUni.subscribe(AsyncResultUni.java:31)
    at io.smallrye.mutiny.operators.AbstractUni.subscribe(AbstractUni.java:36)
    at io.smallrye.mutiny.operators.uni.UniOnItemTransformToUni.subscribe(UniOnItemTransformToUni.java:25)
    at io.smallrye.mutiny.operators.AbstractUni.subscribe(AbstractUni.java:36)
    at io.smallrye.mutiny.operators.uni.UniBlockingAwait.await(UniBlockingAwait.java:60)
    at io.smallrye.mutiny.groups.UniAwait.atMost(UniAwait.java:65)
    at io.quarkus.redis.runtime.datasource.BlockingPubSubCommandsImpl$BlockingRedisSubscriber.unsubscribe(BlockingPubSubCommandsImpl.java:127)
.......
    at io.quarkus.arc.impl.EventImpl$Notifier.notifyObservers(EventImpl.java:351)
    at io.quarkus.arc.impl.EventImpl$Notifier.notify(EventImpl.java:333)
    at io.quarkus.arc.impl.EventImpl.fire(EventImpl.java:80)
    at io.quarkus.arc.runtime.ArcRecorder.fireLifecycleEvent(ArcRecorder.java:156)
    at io.quarkus.arc.runtime.ArcRecorder$2.run(ArcRecorder.java:112)
    at io.quarkus.runtime.StartupContext.runAllAndClear(StartupContext.java:79)
    at io.quarkus.runtime.StartupContext.close(StartupContext.java:70)
    at io.quarkus.runner.ApplicationImpl.doStop(Unknown Source)
    at io.quarkus.runtime.Application.stop(Application.java:208)
    at io.quarkus.runtime.Application.stop(Application.java:155)
    at io.quarkus.runtime.ApplicationLifecycleManager$ShutdownHookThread.run(ApplicationLifecycleManager.java:460)
    at org.graalvm.nativeimage.builder/com.oracle.svm.core.thread.PlatformThreads.threadStartRoutine(PlatformThreads.java:896)
    at org.graalvm.nativeimage.builder/com.oracle.svm.core.thread.PlatformThreads.threadStartRoutine(PlatformThreads.java:872)

I am following the guide on "Communicate with pub/sub" as documented on the Quarkus website. https://quarkus.io/guides/redis-reference#communicate-with-pubsub and maybe he exception occurs during the execution of the unsubscribe() method on the Redis subscriber.
And maybe the problem occures when call `subscriber.unsubscribe();

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

java 21.0.2 2024-01-16 LTS

Quarkus version or git rev

3.15.2

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @Ladicek (redis), @cescoffier (redis), @machi1990 (redis)

[cescoffier]

@Ladicek, I'm surprised it breaks after an update. It looks like we no longer have the DB instance for the pub/sub connection. Did you change something in the Vert.x client? I still think we should be more defensive and fix it in Quarkus, but I would like to know where it changed.

[Ladicek]

Doesn't ring a bell. I'll have to look deeper. @iqnev do you possibly have more detailed instructions for reproducing, ideally a minimal reproducer project?

[iqnev]

Hi @Ladicek I attempted to create a straightforward reproducer; however, the process proved to be challenging. Nonetheless, I successfully isolated the Redis pub/sub that my application utilizes at https://github.com/iqnev/quarkus-redis-reproducer. Unfortunately, I was unable to reproduce the error. :(

[Ladicek]

OK, I think I see what's going on. The Vert.x Redis instrumenter is not guaranteed to always set db.instance, because it isn't always available. Specifically, if the connection is "tainted", there will be no db.instance, because it simply isn't known. This happens for example if you get a connection and execute the select command.