-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Akka.Remote: log all layers of wrapped messages during errors #6818
Akka.Remote: log all layers of wrapped messages during errors #6818
Conversation
Make sure we capture what the real underlying message types are when we encounter issues like serialization errors, oversized payload exceptions, and so on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is primarily a debuggability improvement - it doesn't really impact the execution of Akka.Remote much. I'm looking to add this in order to track down some Akka.Cluster.DistributedData improvement areas related to large payload sizes.
TestActor); | ||
|
||
var loggedType = EndpointWriter.LogPossiblyWrappedMessageType(wrappedMessage); | ||
loggedType.Should().Contain("DeadLetter").And.Contain("ActorSelectionMessage").And.Contain("String"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Simple unit test to assert that our log formatting helper captures all of the layers correctly.
This test produces the following output in the log:
Akka.Event.DeadLetter-->(Akka.Actor.ActorSelectionMessage-->System.String)
@@ -1486,7 +1522,7 @@ private bool WriteSend(EndpointManager.Send send) | |||
string.Format("Discarding oversized payload sent to {0}: max allowed size {1} bytes, actual size of encoded {2} was {3} bytes.", | |||
send.Recipient, | |||
Transport.MaximumPayloadBytes, | |||
send.Message.GetType(), | |||
LogPossiblyWrappedMessageType(send.Message), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Captured all of the relevant EndpointWriter
callsites here - unfortunately, on the EndpointReader
side we don't know what the underlying type is because it fails during deserialization, which is where we would extract that kind of information.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Changes
Make sure we capture what the real underlying message types are when we encounter issues like serialization errors, oversized payload exceptions, and so on.
Checklist
For significant changes, please ensure that the following have been completed (delete if not relevant):