Close the delayed log handler if exception #20797
Conversation
| @@ -194,6 +195,9 @@ public void close() throws Throwable { | |||
|
|
|||
| return state; | |||
| } catch (Throwable e) { | |||
| if (!InitialConfigurator.DELAYED_HANDLER.isActivated()) { | |||
| InitialConfigurator.DELAYED_HANDLER.close(); | |||
There was a problem hiding this comment.
Wouldn't activate make more sense here?
There was a problem hiding this comment.
Well, activate() is private so no :).
And it won't work. If the handler has not been activated, we don't have any nested handler contributed by the Quarkus bootstrap so we somehow have to push the log records ourselves.
There was a problem hiding this comment.
Ah right, was thinking of something else.
There was a problem hiding this comment.
I remembered: LoggingSetupRecorder.handleFailedStart(); is what I was after
There was a problem hiding this comment.
Maybe we should register a shutdown hook instead in io.quarkus.bootstrap.logging.InitialConfigurator? Also LoggingSetupRecorder.handleFailedStart(); is potentially better than just calling close, as it will mostly respect the logging settings.
gsmet
force-pushed
the
close-delayed-handler
branch
from
5d19217 to
5f15374
Compare
| @@ -36,8 +38,6 @@ | |||
| public static final ExtensionContext.Namespace NAMESPACE = ExtensionContext.Namespace | |||
| .create("io.quarkus.test.main.jvm"); | |||
|
|
|||
| private static Map<String, String> devServicesProps; | |||
If the handler has not been activated, we flush the content of the log when we have an exception. Otherwise, the user is missing important information. This is especially important when a resource does not start properly.
gsmet
force-pushed
the
close-delayed-handler
branch
from
5f15374 to
794c71b
Compare
gsmet
added
the
triage/waiting-for-ci
Failing Jobs - Building 794c71b
Full information is available in the Build summary check run. Failures⚙️ JVM Tests - JDK 17 #- Failing: extensions/smallrye-reactive-messaging-kafka/deployment
! Skipped: integration-tests/kafka-oauth-keycloak integration-tests/kafka-sasl-elytron integration-tests/kubernetes/quarkus-standard-way-kafka and 2 more📦 extensions/smallrye-reactive-messaging-kafka/deployment✖ |
quarkus-bot
bot
removed
the
triage/waiting-for-ci
If the handler has not been activated, we flush the content of the log
when we have an exception. Otherwise, the user is missing important
information.
This is especially important when a test resource does not start properly.
@stuartwdouglas could you have a look at this one? I saw a user complain about this and I also had the issue lately in the quickstarts and this helped. I'm not sure if I have found all the potential places I should adjust. Any other you have in mind?