gRPC testing with a GUI, a file, and a CI runner.

Server-streaming, yes: response.body becomes an array of decoded messages you can assert on and capture from. Client-streaming and bidirectional-streaming methods are not supported yet, and this page says so rather than hiding it under a protocols checkmark. Unary calls are fully supported, with metadata, TLS to the target, a per-call deadline, and retry.

No, if the server exposes reflection. A grpc node takes exactly one of proto (a local .proto file, with importPaths for its imports) or reflection: true, in which case Bandura fetches the service description from the server itself. Reflection is the faster start; a checked-in .proto keeps the test self-contained and reviewable, which is usually what a repo wants.

response.status is the gRPC status code, 0 meaning OK, and a non-OK status is deliberately not a failure on its own: NOT_FOUND is a legitimate thing to test for. Assert response.status === 0 when success is what you expect, exactly as you assert a 2xx on HTTP. The decoded response message is response.body, or an array of messages for a server-streaming method.

Yes, as one node covering the whole exchange: open the socket (ws:// or wss://, with handshake headers and optional subprotocols), optionally send one message, collect reply frames until a count or a waitFor predicate is met, and close. response.body is the array of frames, parsed as JSON where possible, and response.status is the close code. If the expected frames never arrive, the node fails loudly at the timeout instead of hanging.

Yes, as an sse block on an ordinary request node, which is the protocol behind most streaming LLM APIs and live-update endpoints. The event stream is collected into response.body as an array of { event, data } objects, with data parsed as JSON where it is JSON. Collection stops at expectEvents, a truthy waitFor, the stream ending, or the timeout, and asking for events that never arrive is a failure, not a quiet short read.

Yes, and that is the argument for a flow format over a per-protocol client. Every step stores { status, headers, body }, so a flow can log in over REST, call a gRPC method with the captured token in its metadata, wait for the WebSocket event the call should trigger, and assert on all three, with conditions, loops and retry between the steps. Flow-level hooks run around every request-like node, gRPC and WebSocket included.

Yes. The same retry block a request node takes (maxAttempts, delayMs, an optional until predicate) works on grpc and websocket nodes, so polling a gRPC method until a job settles is configuration rather than a loop you write. This is worth stating because it once was not true: a bug where a declared retry on those two node types silently did nothing was found and fixed; the fix is in the current build.

Through metadata, which carries credentials the way HTTP headers do: an authorization entry with a Bearer token, an API key, whatever the service expects, each value interpolated with ${{ }} so it can come from env.* or from a capture two nodes earlier. A common shape is a REST login step whose captured token lands in the gRPC metadata. Set tls: true when the target speaks TLS, and flow-level hooks wrap grpc nodes like any other call, so a signing hook covers them too.