Single onNext() on a server-streaming call is not flushed to the wire until a second write or stream close happens

[bishalraiganj]

I'm seeing gRPC-Java (grpc-netty-shaded 1.72.0) not flush a DATA frame to the
socket for a server-streaming RPC when the handler calls onNext() exactly
once and never calls onNext() again or onCompleted()/onError() afterward.

Repro:

@OverRide
public void getTransferStatus(TransferStatusRequest request,
StreamObserver responseObserver) {
responseObserver.onNext(TransferStatusResponse.newBuilder()
.setStatus("Update 0 time: " + LocalDateTime.now())
.build());
// deliberately nothing else called — no onCompleted(), no more onNext()
}

Verified with two independent clients (grpcurl and Postman) — neither
receives the message. If I later add a second onNext() (even minutes
later via a separate ScheduledExecutorService thread) or call
onCompleted(), the FIRST message is delivered at that point, not when
onNext() was originally called — both timestamps show up on the client
close together.

Ruled out so far:

• Not a client-side rendering delay (two unrelated clients agree).
• Not simply "blocking the call-handling thread" — the first onNext()
  happens instantly on the original call thread, no sleep before it,
  and it's still withheld.
• Not related to onCompleted() specifically — the same withholding
  happens even if onCompleted() is never called; ANY second event on
  the stream flushes the backlog.

Question: What is the actual trigger gRPC-Java/Netty uses to flush a
pending onNext() write for a server-streaming call — is there a
write-coalescing/batching mechanism (e.g. tied to WriteQueue,
periodic flush, or channel writability) that withholds a single queued
message until a second write event occurs? Is there a supported way
(e.g. via ServerCallStreamObserver, channel options, or a builder flag)
to force an immediate flush after a single onNext() with no further
activity?

Setup: Spring-less plain ServerBuilder.forPort(...), grpc-netty-shaded
1.72.0, Java 21, Windows, plaintext (no TLS).

[lMysticl]

A genuine server-streaming descriptor should not wait for a second write in 1.72.0. ServerCallImpl.sendMessageInternal() writes the message and immediately calls stream.flush() whenever the method does not have serverSendsOneMessage() semantics: ServerCallImpl.java lines 156–171.

That makes the runtime method type the first thing to check:

System.out.println(
        TransferServiceGrpc.getGetTransferStatusMethod().getType());

For the method you described, this must print:

SERVER_STREAMING

and the proto declaration must contain stream on the response:

rpc GetTransferStatus(TransferStatusRequest)
    returns (stream TransferStatusResponse);

If the descriptor prints UNARY (or CLIENT_STREAMING), gRPC deliberately skips the flush because that method type promises one server response followed by status. Calling onCompleted() closes and flushes it; a second onNext() violates the one-response contract and also drives the call toward closure, which explains why the first buffered message then becomes visible.

The likely causes are stale generated *Grpc sources/classes, a server registering an older generated service, or client and server artifacts built from different proto definitions. Regenerate both sides and check for duplicate/older generated classes on the runtime classpath.

There is no supported ServerCallStreamObserver.flush() switch to add here. If the runtime descriptor really is SERVER_STREAMING and this still reproduces, then it contradicts the explicit 1.72.0 flush path above and would be worth reducing to a small repository as a transport bug.