[Zaczero]

The gateway client's Container.Start and ContainerProcess.Wait can hang indefinitely when the shared ExecProcess stream ends while their caller contexts remain live. The receive loop stops delivering messages, but the per-process receivers only observe their caller's context and deregistration. Transport errors cancel the forwarder's errgroup context without reaching those receivers; EOF and gRPC cancellation return nil without canceling it.

Cancel the forwarder's context with the receive error on every stream termination, including EOF and cancellation, and have process receivers observe that context. Return the cancellation cause directly from the mailbox, so Start and Wait propagate it through their existing error paths. Keep the existing Release behavior for EOF and cancellation, and use the existing output-handler cleanup to unblock pending stdin.

The regression uses a real gRPC server on a loopback listener. It terminates the stream with EOF, Unavailable, Canceled and DeadlineExceeded, both before Started and while waiting for completion, with two processes sharing the stream and stdin left open. It checks that both calls return the transport failure while their caller context is still live. Separate completed-process cases verify that Exit and Done followed by stream termination still produce successful waits. Each case also checks that Release still returns nil for EOF and cancellation and the transport error otherwise.

Validation:

• All eight in-flight failure cases time out against unmodified master.
• go test -race ./frontend/gateway/grpcclient -count=100 -timeout=120s passes, including the four completed-process cases.
• golangci-lint run ./frontend/gateway/grpcclient/...

[Zaczero]

ci failure appears unrelated

[crazy-max]

ci failure appears unrelated

yes maybe a startup race in containerd FIFO handling. Created #7301

[crazy-max]

While checking the completed-process cases with stdin left open, I reproduced a case where the cleanup EOF send replaces a successful process result with io.EOF:

--- FAIL: TestProcessStdinEOF/successful_process_with_open_stdin
    Error: Received unexpected error:
           EOF

A loopback gRPC test also reproduced this when the server sent Exit and Done, then ended the stream while stdin remained open (with a stub server, not full BuildKit daemon)

The additiional commit keeps sending EOF because the gateway needs it before sending Done, but ignores send failures when cleanup closed the input pipe. Errors from sending a natural input EOF still propagate.

I also added coverage for stream termination between Exit and Done:

$ CGO_ENABLED=1 go test -mod=vendor -race ./frontend/gateway/grpcclient -count=100 -timeout=120s
ok  github.com/moby/buildkit/frontend/gateway/grpcclient  15.551s