4 Commits (148b19b0d7e36b6f2b8a169d2cb7b6069ab5d00a)

Author	SHA1	Message	Date
Radek Simko	30aa3cb743	rpcapi: Add missing license headers & code-generation headers (#34617)	2 years ago
Martin Atkins	ac93c1bb82	rpcapi: Add HashiCorp copyright comments	2 years ago
Martin Atkins	97ee2f14c3	rpcapi: codegen for RPC functions with streaming responses ... Our generator for the wrapper stubs for the dynamically-instantiated gRPC services could not previously handle the slightly different signature used for the methods generated for RPC functions that return streaming responses: they take a stream object as an argument instead of returning a message directly. Now we can generate wrapper stubs for those methods too, so that subsequent commits can include the real implementations of those functions. This commit includes just an unimplemented husk of Stacks.PlanStackChanges as a placeholder to demonstrate that it's working.	2 years ago
Martin Atkins	14759c1d04	rpcapi: A different approach to late server initialization ... Previously we were trying to add new services to the gRPC server after it was already running, which worked okay in the contrived fake setup I was using to test it in isolation but is rejected by the real gRPC server implementation, which requires all service registration to happen prior to starting the server. Instead then, we'll use some wrapper server implementations that initially just return "Unavailable" errors for every request but can then be tardily initialized with a real server implementation that takes over serving requests once registered. This involves some gnarly code generation for the wrapper server implementations because this situation is beyond the current capabilities of Go generics. The code generator implementation is pretty gross but this approach was the least horrible of various other things I tried in order to avoid writing a code generator. The code generator may need some additional work later once we introduce our first streaming RPC function, but after that it should hopefully remain unchanged for a long time as long as we stick to the current API design idiom for future services.	2 years ago