Request has already been read (Vertx)

[gwenneg]

Describe the bug

I updated Quarkus from 1.9.0 to 1.13.x in a project recently and ran into the following exception:

java.lang.IllegalStateException: Request has already been read
	at io.vertx.core.http.impl.HttpServerRequestImpl.checkEnded(HttpServerRequestImpl.java:596)
	at io.vertx.core.http.impl.HttpServerRequestImpl.handler(HttpServerRequestImpl.java:306)
	at io.quarkus.vertx.http.runtime.ResumingRequestWrapper.handler(ResumingRequestWrapper.java:18)
	at io.vertx.ext.web.impl.HttpServerRequestWrapper.handler(HttpServerRequestWrapper.java:82)
	at io.vertx.ext.web.handler.impl.BodyHandlerImpl.handle(BodyHandlerImpl.java:86)
	at io.vertx.ext.web.handler.impl.BodyHandlerImpl.handle(BodyHandlerImpl.java:42)
	at io.vertx.ext.web.impl.RouteState.handleContext(RouteState.java:1038)
	at io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:137)
	at io.vertx.ext.web.impl.RoutingContextImpl.next(RoutingContextImpl.java:132)
	at io.quarkus.vertx.http.runtime.VertxHttpRecorder$4.handle(VertxHttpRecorder.java:338)
	at io.quarkus.vertx.http.runtime.VertxHttpRecorder$4.handle(VertxHttpRecorder.java:316)
	at io.vertx.ext.web.impl.RouteState.handleContext(RouteState.java:1038)
	at io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:137)
	at io.vertx.ext.web.impl.RoutingContextImpl.next(RoutingContextImpl.java:132)
	at io.quarkus.vertx.http.runtime.devmode.VertxHttpHotReplacementSetup$3.handle(VertxHttpHotReplacementSetup.java:86)
	at io.quarkus.vertx.http.runtime.devmode.VertxHttpHotReplacementSetup$3.handle(VertxHttpHotReplacementSetup.java:75)
	at io.vertx.core.impl.ContextImpl.lambda$null$0(ContextImpl.java:327)
	at io.vertx.core.impl.ContextImpl.executeTask(ContextImpl.java:366)
	at io.vertx.core.impl.EventLoopContext.lambda$executeAsync$0(EventLoopContext.java:38)
	at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
	at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:834)

It is thrown randomly if a BodyHandler is appended to a route and that route is then called from an HTTP request:

    @PostConstruct
    public void init(@Observes Router router) {
        router.route().handler(BodyHandler.create());
        router.get("/test").handler(this::doSomething);
    }

Expected behavior

No exception thrown.

Actual behavior

HTTP request is served sometimes, and sometimes it fails because of the exception.

To Reproduce

https://github.com/gwenneg/quarkus-request-already-read

Steps to reproduce the behavior:

1. ./mvnw clean quarkus:dev
2. Open http://localhost:8080/test in a browser and refresh the page until it fails.

Environment (please complete the following information):

Output of java -version

openjdk version "11.0.9.1" 2020-11-04
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.9.1+1)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.9.1+1, mixed mode)

Quarkus version or git rev

1.13.2.Final

[gwenneg]

BodyHandlerBean may play a role in this but I'm really not sure.

[gwenneg]

cc @cescoffier @stuartwdouglas

[gwenneg]

It seems the exception is only thrown for requests which are not supposed to have a body (GET for example). On the other hand, a request with a body (like POST) seems to always be served correctly.

[gwenneg]

Workaround: append a BodyHandler only to routes that actually need to access the request body.

[stuartwdouglas]

I think this may already be fixed by #16460

[stuartwdouglas]

Actually probably not, if this still happens in 1.13.2

[cescoffier]

@geoand fixed an issue related to that recently.

[geoand]

Indeed, @gwenneg can you retest?

[gwenneg]

Is your fix included in 1.13.6 @geoand?

[geoand]

I don't think we backported it

[gsmet]

Which one is it? I will probably prepare a new 1.13 this week.

[geoand]

#17551

I just added the backport label

[cescoffier]

Closing - looks outdated. Please reopen if the problem remains.