I noticed that raising a BadOutOfRangeError in a server callback set through Server.subscribe_server_callback resulted in a BadInternalError on the client side (tested with UaExpert) rather than the expected BadOutOfRange. But raising a
ServiceError(ua.StatusCodes.BadOutOfRange) instead would show the the expected BadOutOfRange error in the client.
The reason for this idiosyncrasy was that UaStatusCodeErrors were not explicitly caught. Therefore the "default" except Exception handler would be used which resulted in a
ua.StatusCode(ua.StatusCodes.BadInternalError) to be sent to the client instead of the actual status code of the error that occurred.
This commit changes the behavior such that the status code of UaStatusCodeErrors is respected the same way as it's already done for ServiceErrors so that the client correctly receives the status code of the raised error.
I noticed that raising a
BadOutOfRangeErrorin a server callback set throughServer.subscribe_server_callbackresulted in a BadInternalError on the client side (tested with UaExpert) rather than the expected BadOutOfRange. But raising aServiceError(ua.StatusCodes.BadOutOfRange)instead would show the the expected BadOutOfRange error in the client. The reason for this idiosyncrasy was thatUaStatusCodeErrors were not explicitly caught. Therefore the "default"except Exceptionhandler would be used which resulted in aua.StatusCode(ua.StatusCodes.BadInternalError)to be sent to the client instead of the actual status code of the error that occurred.This commit changes the behavior such that the status code of
UaStatusCodeErrors is respected the same way as it's already done forServiceErrors so that the client correctly receives the status code of theraised error.See also https://github.com/FreeOpcUa/opcua-asyncio/discussions/1563#discussioncomment-8382555