Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: custom failure status code support #847

Merged
merged 1 commit into from
Mar 21, 2022
Merged

Conversation

jroper
Copy link
Member

@jroper jroper commented Mar 9, 2022

Added support for custom status codes to both Java and Scala SDKs.

This is to match feature parity with lightbend/kalix-javascript-sdk#253.

@github-actions github-actions bot added the kalix-runtime Runtime and SDKs sub-team label Mar 9, 2022
Copy link
Contributor

@raboof raboof left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Refs #830

Limitation of this implementation is that you can only specify an error code, but not add a customer 'message' or additional protobuf-serialized 'details' objects. Seems fine to me.

Some comments for consideration and one probably accidentally-committed change, otherwise LGTM!

samples/java-valueentity-customer-registry/pom.xml Outdated Show resolved Hide resolved
* @return An error reply.
* @param <T> The type of the message that must be returned by this call.
*/
<T> Effect<T> error(String description, GrpcStatus status);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess in the future we might introduce yet another variant to also be able to control the HTTP status code (when transcoding), but this is 👍.

* @return
* An error reply.
* @tparam T
* The type of the message that must be returned by this call.
*/
def error[T](description: String): Effect[T]
def error[T](description: String, status: Option[GrpcStatus] = None): Effect[T]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want to support controlling HTTP status codes through this API as well, that default parameter might make it harder to evolve in a binary compatible way - but I guess for the SDK we care mainly about source compatibility and not so much about bincompat?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the most commonly used HTTP status codes, there's a corresponding gRPC status code that we map to it in the HTTP transcoding.

But yes, my thinking here was that source compatibility is the most important thing.

@jroper
Copy link
Member Author

jroper commented Mar 9, 2022

Limitation of this implementation is that you can only specify an error code, but not add a customer 'message' or additional protobuf-serialized 'details' objects.

The existing description parameter that's passed is passed to the standard grpc-message trailer. There are no other defined trailer values to pass, however, it might make sense at some point to add an optional Metadata object to the protocol and hence to the SDK APIs that gets added to the trailers if present.

@raboof
Copy link
Contributor

raboof commented Mar 9, 2022

Limitation of this implementation is that you can only specify an error code, but not add a customer 'message' or additional protobuf-serialized 'details' objects.

The existing description parameter that's passed is passed to the standard grpc-message trailer.

Of course, forgot about that. In that case it might be neat to have an error overload that takes only the code (and infers the default message from that), but not essential.

There are no other defined trailer values to pass, however, it might make sense at some point to add an optional Metadata object to the protocol and hence to the SDK APIs that gets added to the trailers if present.

Yeah, there's a convention to add a grpc-status-details-bin header but that's not yet widely documented (grpc/grpc#24007)

@ennru
Copy link
Member

ennru commented Mar 18, 2022

@jroper Do you intend to finish this, or should someone else take over?

@jroper
Copy link
Member Author

jroper commented Mar 19, 2022

Yes I'll finish it.

Added support for custom status codes to both Java and Scala SDKs.
def error[S](description: String): Action.Effect[S] = ErrorEffect(description, Nil)
def error[S](description: String): Action.Effect[S] = ErrorEffect(description, None, Nil)
def error[S](description: String, statusCode: Status.Code): Action.Effect[S] = {
if (statusCode.toStatus.isOk) throw new IllegalArgumentException("Cannot fail with a success status")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Future.successful(
ActionResponse(
ActionResponse.Response.Failure(Failure(description = description)),
ActionResponse.Response.Failure(
Failure(description = description, grpcStatusCode = status.map(_.value()).getOrElse(0))),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, 0 does not mean SUCCESS but 'unspecified' here, an will be converted to UNKNOWN in the proxy. Not super obvious but 👍

@jroper jroper merged commit 09cb1a0 into lightbend:main Mar 21, 2022
@jroper jroper deleted the grpc-status branch March 21, 2022 11:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kalix-runtime Runtime and SDKs sub-team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants