Vision on error handling in the server

[timocov]

I understand that server-side packages are still in developer preview and I don't expect you to have an answer for this question, but I'm curious what is your thinking on the following problem.

When building a server, one of the things that Smithy provides is error declaration and as a result, server implementations can be more opinionated about errors, for instance, if an operation doesn't have a thrown exception in the list of its errors (either directly or via the service shape) - fallback to "internal server error" to avoid breaking the contract.

This exact pattern I noticed in the server protocol in this package -

smithy-java/server/server-core/src/main/java/software/amazon/smithy/java/server/core/ServerProtocol.java

Lines 60 to 65 in 146172b

	// Check both implicit errors and operation errors to see if modeled API exception is
	// defined as part of service interface. Otherwise, throw generic exception.
	if (!job.operation().getOwningService().typeRegistry().contains(error.schema().id())
	&& !job.operation().getApiOperation().errorRegistry().contains(error.schema().id())) {
	error = InternalFailureException.builder().withCause(error).build();
	}

This is a wonderful feature that I'd want to have as well, but the problem is the following.

Assume you have Service A and Service B, A calls B. Both services use smithy to generate clients/servers and both share some common types e.g. framework-errors provided by Smithy. Now, if both services use a shared error (e.g. ValidationException or InternalServerError from framework-errors), and when service A calls service B, and service B returns such error ValidationException, and service A doesn't have an explicit handling for it at the place of the call, instead of resulting in 500, it will be just re-translated back because service A also has this error defined in its error registry.

I thought that it might be possible to use instanceof check instead, but because such shared types would normally provide generated classes, it wouldn't help (because it would be the same jar for both service A dependency and service B client's dependency).

So I had a couple of ideas in mind that potentially might work, but I'm curious what was your thinking for this problem:

• in theory, in the generated clients we can somehow mark exceptions generated from the clients to differentiate them between server-originated and "dependency-originated". But given generated classes are out of control, this unlikely is not going to work
• during the model processing, for any "shared" types we can "merge them in" into the service's model so that "shared" types become "own" types (e.g. their namespaces would change from say smithy.framework to servicename) and then run the codegen for them (probably it will do automatically anyway). I guess this should work, but this would require model processing not just during the codegen, but during the model publishing as well so that consumers would get the actual model state, not "raw".

If you see this as a problem of the servers using smithy-java (in the future when it comes out from developer preview), I'm curious what approach you'd take to handle this.

Thanks!