`HubException` message is always "wrapped", contrary to documentation

[milesizzo]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

According to the SignalR documentation, when throwing a HubException from a hub method, SignalR should "[send] the entire exception message to the client, unmodified." However, the actual behavior wraps the message:

// Server
throw new HubException("{\"code\":0}");

// Client receives
"An unexpected error occurred invoking 'MethodName' on the server. HubException: {\"code\":0}"

This is caused by ErrorMessageHelper.BuildErrorMessage() which - in the case of HubException - formats the message as:

aspnetcore/src/SignalR/server/Core/src/Internal/ErrorMessageHelper.cs

Lines 10 to 13 in a9aaa32

	if (exception is HubException || includeExceptionDetails)
	{
	return $"{message} {exception.GetType().Name}: {exception.Message}";
	}

This occurs when throwing the exception from a hub method and from a filter.

Describe the solution you'd like

The HubException.Message should be passed through unmodified to the client, as documented.

Alternatively, update the documentation to clarify this behaviour.

Additional context

Here is a sample use-case:

Passing JSON error payloads to clients:

// Server
throw new HubException("{\"code\":\"USER_NOT_FOUND\"}");

// Client receives
"An unexpected error occurred invoking 'GetUser' on the server. HubException: {\"code\":\"USER_NOT_FOUND\"}"

The client cannot directly deserialize this as JSON without first stripping the prefix.

This is similar to the following issues:

• SignalR HubException should allow passing a structured data object back to the caller #7722
• SignalR HubException does not send innerException property #12633
• [SignalR] Possibility to catch custom (hub)exceptions in client #11891

However I feel it is different enough to warrant a separate report.

If this behaviour is not desired, what is the recommended method for handling/parsing errors on the client?

[BrennanConroy]

Sure, we could be a little clearer in the docs. A few lines up in the doc we give an example of a non-HubException error that's returned to the client, so we can probably include an example with a HubException.

If you want to parse the error then it should be easy to strip the prefix JSON.parse(error.split('HubException: ')[1])

[milesizzo]

Parsing out the string from SignalR feels like a fragile solution for dealing with errors. Is there a reason that explicit HubException exceptions thrown by user code need to be wrapped?

Having the ability to create an IHubFilter that catches known exceptions in hub methods and return well-formed error messages/codes is quite powerful (and follows a similar pattern to ASP .NET Core IExceptionFilter). If the appetite for changing the existing implementation is not there, introducing an IHubExceptionFilter interface to customize the error handling could also be a nice addition. This could be made backwards compatible (e.g. no exception filter = current behaviour).