azure-functions-durable-extension: Failed to deserialize SqlException from TaskActivity
Error similar to the one fixed in #459 is still happening in some cases in v1.8.0.
I have a much simpler case where simple orchestrator calls an activity that executes some SQL query. The query fails and activity throws SqlException. It seems that this kind of exception is especially nasty to serialize:
Microsoft.Azure.WebJobs.FunctionFailedException: The activity function 'GetViewers' failed: "Failed to deserialize exception from TaskActivity: {"$type":"System.Data.SqlClient.SqlException, System.Data.SqlClient","ClassName":"System.Data.SqlClient.SqlException","Message":"Invalid object name 'ActiveViewer_1_19'."
The whole stack trace is very long, but I think this is an interesting part:
System.InvalidCastException: Unable to cast object of type 'Newtonsoft.Json.Linq.JValue' to type 'System.Guid'. at System.Data.SqlClient.SqlException..ctor(SerializationInfo si, StreamingContext sc) at lambda_method(Closure , Object[] ) at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateISerializable(JsonReader reader, JsonISerializableContract contract, JsonProperty member, String id)
There is indeed a Guid field in SqlException and it seems it causes the serialization issue:
"ClientConnectionId":"b8c66db2-dfcc-47f1-9f33-f3863f07b387"
This should be very easy to reproduce. Just make an activity that executes wrong SQL.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 2
- Comments: 18 (10 by maintainers)
That’s completely fair @junalmeida. My main hesitation is that there are alot of official Microsoft libraries, and making sure we serialize all of the exceptions from each of them (even just the most commonly used ones) would put a fairly large burden on us as a development team, especially since new libraries are being created all of the time.
Ideally, each library’s developers should ensure that their data/exceptions is more easily serializable with common serialization libraries. In this specific case, it looks like the SqlException defined in versions greater than v2.0.0 of Microsoft.Data.SqlClient works much better with Newtonsoft than the version defined inthe legacy
System.Data.SqlClientnamespace.As for this specific exception, it looks like the owner of that library are working to make it work better with serialization in their new major version: https://github.com/dotnet/SqlClient/issues/524.