Bradley Kemp
Bradley Kemp
Currently the Forwarded header is overwritten. We should be standards compliant and append values instead to reflect the full path the request may have been proxied through. https://github.com/vfaronov/httpheader looks good...
The upgrade to grpc-go (https://github.com/bradleyjkemp/grpc-tools/pull/33) broke failed the integration tests because the user agent changed. This shouldn't happen because `grpc-replay` should send the user agent from the dump instead of...
Some gRPC services (e.g. reflection API or server healthcheck/status) are implemented by multiple servers which can return different results. grpc-fixture should be able to return different responses depending on the...
When writing fixtures or writing dumps to be replayed for testing purposes, it would be much nicer to be able to write messages in the human readable form rather than...
Related: #1 A very common flow is for the client to send a Create request and receive in response some sort of handle that they can later use to Read/Update/Delete...
Related to #24 `grpc-replay` is currently unable to assert that the server returns the same error as the dump that is being replayed. At the moment it only checks that...
At the moment `grpc-fixture` isn't able to replay errors from a dump. Both the fixture loading code needs to be extended to support errors and the fixture interceptor needs to...
Without a proper specification of the dump output format it's hard for users to write parsers, etc. for the output of `grpc-dump`.
Currently the dump format does not include any information about which RPCs came in from the same client/connection. This information is probably accessible through the request context? Adding this information...
Things that could be matched on: - Do request/response messages need to be an exact (byte-level) match of those in the dump? - Is it possible to ignore mismatches in...