StdioServerTransportProvider uses incorrect Mono.zip operator #303

Activity

1. chemicL commented on Feb 18, 2026

   

   chemicL

   on Feb 18, 2026

   Member

   More actions

   Thanks for the heads up. I think the warnings come from Intellij Idea and I think they are inaccurate. Perhaps you'd like to report it in their issue tracker?

   However, I think the used operator is probably not the right one and when should be used instead. Compare:

   public static void main(String[] args) throws InterruptedException {
   		Mono.zip(
   				Mono.delay(Duration.ofSeconds(2)).then().doOnCancel(() -> System.out.println("Slower mono cancelled!")),
   				Mono.delay(Duration.ofSeconds(1)).then().doOnCancel(() -> System.out.println("Faster mono cancelled!"))
   		)
   		.subscribe(
   				x -> System.out.println("Value: " + x),
   				e -> System.err.println("Error: "+ e),
   				() -> System.out.println("Completed")
   		);
   
   		Thread.sleep(3000);
   	}
   }
   
   // prints after 1s:
   // Slower mono cancelled!
   // Completed

   with

   public static void main(String[] args) throws InterruptedException {
   		Mono.when(
   				Mono.delay(Duration.ofSeconds(2)).then().doOnCancel(() -> System.out.println("Slower mono cancelled!")),
   				Mono.delay(Duration.ofSeconds(1)).then().doOnCancel(() -> System.out.println("Faster mono cancelled!"))
   		)
   		.subscribe(
   				x -> System.out.println("Value: " + x),
   				e -> System.err.println("Error: "+ e),
   				() -> System.out.println("Completed")
   		);
   
   		Thread.sleep(3000);
   	}
   }
   
   // prints after 2s:
   // Completed

   So for this particular use case I believe we should wait for both inbound and outbound streams. Let me mark the issue as a good first issue.
2. chemicL

   changed the title [-]Suspicious call to Mono.zip?[/-] [+]StdioServerTransportProvider uses incorrect Mono.zip operator[/+] on Feb 18, 2026
3. chemicL

   added

   good first issueGood for newcomersGood for newcomers

   ready for workThe goal is clear and work towards it can be commencedThe goal is clear and work towards it can be commenced

   bugSomething isn't workingSomething isn't working

   on Feb 18, 2026
4. chemicL

   added the

   Bug

   issue type on Feb 18, 2026
5. chemicL

   added

   P3Nice to haves, rare edge casesNice to haves, rare edge cases

   on Feb 18, 2026
6. rameshreddy-adutla

   added a commit that references this issue on Mar 4, 2026

   Fix: Replace Mono.zip with Mono.when in StdioServerTransportProvider#…

   ...

   This issue will close once commit 7f7e00e is merged into the 'main' branch.

   7f7e00e
7. imankhadiv commented on Aug 11, 2026

   

   imankhadiv

   on Aug 11, 2026

   More actions

   Hi @chemicL — is this still open for a fresh PR?

   The issue is still present on main: StdioServerTransportProvider uses Mono.zip(inboundReady.asMono(), outboundReady.asMono()), and both inboundReady/outboundReady are Sinks.One<Void> that only ever complete empty. Mono.zip requires a value from every source, so the first empty completion completes the combined Mono and cancels the other one — meaning sendMessage can proceed before both streams are actually ready. Mono.when waits for both without cancelling, as you pointed out above.

   There is an existing PR (#846) with this change, but it has had no review since it was opened in March, and two other contributors have since opened and self-closed duplicates deferring to it (#981, #987). If #846 is still the intended path, I will leave this alone. If it is stalled, I would be happy to open a fresh PR with the Mono.when fix plus a regression test that fails on zip and passes on when.
8. rameshreddy-adutla

   added a commit that references this issue on Sep 28, 2026

   Fix stdio readiness barrier to wait for both Mono<Void> signals

   ...

   This issue will close once commit 081605d is merged into the 'main' branch.

   081605d