FabricException ErrorCode changed to Unknown when thrown via Remoting

[0shi]

Describe the bug
A FabricException thrown from user code and returned to another service via Remoting has an ErrorCode property of Unknown when observed at the calling service, regardless of its original ErrorCode.
The HResult appears unchanged, as a workaround we will check the HResult as well as the ErrorCode.

To Reproduce
Source of exception - A Service that will be interacted with via SF Remoting

public async Task DoStuff()   
{   
   var ex = new FabricException(FabricErrorCode.OperationTimedOut);
   throw ex;
}

Reader of exception - A service with a Polly for retrying transient exceptions:

await policy.ExecuteAsync(async () =>   
{   
   // Assume we already have a proxy
   await proxy.DoStuff().ConfigureAwait(false);
}

Expected behavior
ErrorCode is the same at the source and the caller.

Additional context
Observed while developing a retry wrapper around SF Remoting operations for transient SF exceptions and intentionally throwing a FabricException from user code to test the wrapper. Unsure if the same behaviour would be present if the FabricException had originated in the SF internals.

[suchiagicha]

@0shi
Yes , it is expected to not work. We don't use that way. We use Errorcode property only for interop layer.
Why you are using FabricException. This is very much tied to ServiceFabric.

[0shi]

I'm no longer on this project, but @MagicalFan should be able to answer any follow-up questions.

We encountered this when we were testing our retry policy by intentionally throwing an exception in one service and retrying it in another. If I understand this response correctly, any FabricExceptions thrown across to another Service will have a code of Unknown, and this is intentional?
Can we rely on the hresult, or is it expected that it's impossible for FabricExceptions to be thrown to user code?