mizosoft
Allow to suppress logging with WARNING in FlowSupport.onDroppedException() (particularly when triggered through
A warning is always logged in https://github.com/mizosoft/methanol/blob/3a2e6b5a021c02db10ba99425a47e5a113685632/methanol/src/main/java/com/github/mizosoft/methanol/internal/flow/FlowSupport.java#L163. This was also experienced in the context of https://github.com/apache/maven-resolver/issues/1661. However errors during close can usually be disregarded and should only be logged if explicitly enabled.
Hi @kwin
This is a reasonable request.
FlowSupport::onDroppedException is called when an exception comes from somewhere but can't be propagated further downstream (e.g. because downstream is already completed). This is like Thread.uncaughtExceptionHandler but for reactive-streams. In the issue you've linked, what happens is that closing the InputStream does: cancel Methanol's subscription -> cancel JDK subscription -> JDK subscription issues exception -> Methanol's subscription receives exception but detects that it can't go nowhere -> exception is logged. JDK's subscription shouldn't pass an exception when cancelled, as this violates reactive-streams spec. I realize however that this can spam logs, particularly in this case.
I'll see if this case can be deterministically detected and ignored. Otherwise, the default log level for such exceptions can be set to Level.DEBUG, with the ability to override the level with a system property and maybe set a custom callback.
JDK's subscription shouldn't pass an exception when cancelled, as this violates reactive-streams spec.
I see (https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.4/README.md#3.15). Is this related to https://bugs.openjdk.org/browse/JDK-8347597 (fixed in https://github.com/openjdk/jdk/commit/7df21a8f09ab606f38a44d84d841d4bba9f09adf) or can this still happen in JDK25+?
Reading the spec back, it appears that, although JDK's subscription behavior is awkward, it doesn't actually violate the spec. There is (https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.4/README.md#3.12 & https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.4/README.md#1.8), which state that the publisher/subscription must eventually stop signaling items. This gives leeway for asynchronous signaling to continue till it detects cancellation. However, JDK slips through this awkwardly by signaling the error synchronously.
I'm thinking about doing an ad-hoc e.getMessage().contains("subscription cancelled") to detect this specific case.
https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.4/README.md#3.15 says that subscription.cancel() shouldn't throw an exception, not that it shouldn't signal an exception with onError. It doesn't seem that the linked JDK issue relates to this.