* refactor (controller): Use a grpc server for the grpc-gateway
This starts a grpc server for the grpc-gateway. The new gateway
server uses an in-memory listener which also supports "dialing", so
the http proxy can connect to the in-memory listener.
This change allows us to use all grpc server features and was in part
motivated by a need for an interceptor of inbound requests. With that
said, having a "proper" grpc server for the gateway will provide a lot
more flexibility and capabilities moving forward.
The request context will still be verified via middleware in the
http proxy (see wrapHandlerWithCommonFuncs). This verified context
will be serialized into a protobuf and sent along to the grpc-gateway
via metadata where an interceptor will add the verified request
info to the request's context (see requestCtxInterceptor). The
interceptor will verify the serialized request info via a shared ticket
with it's companion in-memory http proxy. FYI: the ticket is simply
random base62 string (see db.NewPrivateId).
This change also necessitated a minor change to services. We need to
return an empty response instead of nil, nil when there are no errors
and the response is empty.
* refactor (handlers): Rename gRPC Gateway filter
Originally, this was called an OutgoingInterceptor, which is an
unfortunate name since it's not an interceptor. Now that we're
refactoring the gateway stuff and have proper interceptors, renaming
this should remove ambiguity
* refactor: Rework how 204 with empty msg is handled
Recent changes to grpc gateway has necessitated a change to how
204s are handled by the gateway
* tests (bats): Check status codes for delete operations
* add new error funcs which take a ctx and deprecate existing funcs
* use context where available when writing error events
* remove circular internal/errors pkg dep
* suppress some chatty errors using errors.WithoutEvent()
* convert auth oidc funcs to take context where needed to write events
Co-authored-by: Jim <jlambert@hashicorp.com>
This is a wire breaking change for json errors since we have removed and renamed a few fields, and changed part of the structure of the returned json error.
* Remove redundant fields in Status, details.error_id, details.TraceId and details.request_id from API errors.
* Added wrapped errors and "ops" field to indicate the internal operation of the errors returned by the API.
* Added error cli error reporting of Op and wrapped errors.
* Invalid Argument errors now return a per field error message.
* Creating an API error struct.
* SDK uses field error details proto.
* Adding tests specifically for handler helper error messages resulting in expected API output.
* Inlining the error checks into the table driven tests. Use protocmp for assertions to make printing out diffs easier to parse.
* Aggregate the invalid argument fields detected to be wrong.
* Make the returned order of fields deterministic in the error details..
* Fixing formatting issue in errors_test.go.
* Test to confirm unimplemented results in a 405 and not 404.
* Add error handler that converts from rpc.Status errors to Watchtower API errors.
* Better testing for ErrorHandler.
* Rename testcase and remove empty default switch case.
* Change the error status back to int64.
* Converting everything to int32s.
jsonpb wraps int64s as a string which we dont like. We'll figure out how to use values larger than int64s when it comes up.
* Remove special casing for TraceId which isn't needed anymore.
* Removing wrappers from error details since we never need to know when they are set or unset from the end user.
* Using the helper error functions inside the project service.
* Correct usage of hclog, replace panic with Error log.
* Adding periods to all API returned errors, correct spelling, fix missed invalid argument error not using helper function.
* Change our logged errors to Error instead of Warn.
* Add TODO for defining and using our own defined API error codes.
* Add TODO to remove internal error messages.
Jim
s-christoffandJim
Louis Ruch
Todd Knight
Jeff Mitchell