[BUG] Deserializing AcsEmailDeliveryReportReceivedEventData data from EventGridEvent does not populate DeliveryAttemptTimestamp property

[markduregon]

Library name and version

Azure.Messaging.EventGrid 4.24.0

Describe the bug

When I attempt to deserialize the payload of a AcsEmailDeliveryReportReceivedEventData I have received via an Azure Service Bus queue, the object is hydrated correctly except for the DeliveryAttemptTimestamp property.

I have tried both of the following methods as well as a couple of variations on each.

var deliveryReport = JsonSerializer.Deserialize<AcsEmailDeliveryReportReceivedEventData>(eventGridEvent!.Data);

and

if (eventGridEvent.Data is BinaryData binaryData)
{
    var eventData = binaryData.ToObjectFromJson<AcsEmailDeliveryReportReceivedEventData>();
}

In both scenarios the DeliveryAttemptTimestamp property is null, but debugging and looking at the raw data, I know it has a value set.

Additional method now tried and exact same result. Becoming increasingly convinced this is a bug in the JSON converter.

bool success = eventGridEvent.TryGetSystemEventData(out object eventData1);

Example payload is:

{
  "sender": "[email protected]",
  "recipient": "[email protected]",
  "messageId": "b65c4713-17b4-434d-932b-ec75c9af20a8",
  "status": "Delivered",
  "deliveryStatusDetails": {
    "statusMessage": ""
  },
  "deliveryAttemptTimestamp": "2024-06-04T00:13:45.905\u002B00:00"
}

It is possible that it is a bug, I found the following Githug Issue which was related to another issue with this property, so the encoding of the + with \u002B could be messing up the deserialization.

Expected behavior

DeliveryAttemptTimestamp is not null and has the value associated from the payload as it's value.

Actual behavior

DeliveryAttemptTimestamp value is null regardless of method used to deserialize payload.

Reproduction Steps

1. Use Azure Service Bus to queue ACS delivery reports
2. Create a receiver to process the messages
3. Use any of the follwing methods to attempt get the AcsEmailDeliveryReportReceivedEventData information from EventGridEvent and the result is the same for all. All properties except the DeliveryAttemptTimestamp property is set.

EventGridEvent eventGridEvent = EventGridEvent.Parse(args.Message.Body);
if (eventGridEvent.Data is BinaryData binaryData)
{
    var eventData = binaryData.ToObjectFromJson<AcsEmailDeliveryReportReceivedEventData>();
}
bool success = eventGridEvent.TryGetSystemEventData(out object eventData1);
var deliveryReport = JsonSerializer.Deserialize<AcsEmailDeliveryReportReceivedEventData>(json);

Environment

.NET SDK:
Version: 8.0.300
Commit: 326f6e68b2
Workload version: 8.0.300-manifests.4e5ea2d8
MSBuild version: 17.10.4+10fbfbf2e

Runtime Environment:
OS Name: Windows
OS Version: 10.0.22631
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\8.0.300\

.NET workloads installed:
[aspire]
Installation Source: VS 17.10.34916.146, VS 17.11.34909.67
Manifest Version: 8.0.0/8.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.0.0\WorkloadManifest.json
Install Type: FileBased

[maui-windows]
Installation Source: VS 17.11.34909.67
Manifest Version: 8.0.21/8.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.maui\8.0.21\WorkloadManifest.json
Install Type: FileBased

[android]
Installation Source: VS 17.11.34909.67
Manifest Version: 34.0.95/8.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.android\34.0.95\WorkloadManifest.json
Install Type: FileBased

[maccatalyst]
Installation Source: VS 17.11.34909.67
Manifest Version: 17.2.8053/8.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.maccatalyst\17.2.8053\WorkloadManifest.json
Install Type: FileBased

[ios]
Installation Source: VS 17.11.34909.67
Manifest Version: 17.2.8053/8.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.ios\17.2.8053\WorkloadManifest.json
Install Type: FileBased

Host:
Version: 8.0.5
Architecture: x64
Commit: 087e15321b

.NET SDKs installed:
8.0.300 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.19 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.19 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.30 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.19 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

IDE: Visual Studio Professional 17.10.0

[github-actions]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[JoshLove-msft]

I haven't been able to reproduce this bug. Would it be possible for you to include a zipped minimal repro project that I can run?

[github-actions]

Hi @markduregon. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[markduregon]

This is the Windows Service that is using the code above and is experiencing the issue. Hope you are able to get what you need from this to be able to replicate the issue. IMHO I though it might be related to encoding of the timestamp data, whether that is done by ACS putting the message onto the queue, or getting the messge off the queue, I am not sure. But library doesn't appear to be able to handle it either way. I also debugged and tried removing the weird encoding and replacing with a format you would expect and same result. Hence the bug report.

[JoshLove-msft]

I'm not really sure what to look at. I was hoping for a simple console app that includes the payload and the code to deserialize the payload.

[github-actions]

Hi @markduregon. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[markduregon]

AcsEventDemo.zip
OK this is as simple as I could make it.

[markduregon]

Additionally, similar behaviour is also experienced when processing AcsEmailEngagementTrackingReportReceivedEventData events and the UserActionTimestamp is also null.

[JoshLove-msft]

The issue is that the deserialization is expecting "deliveryAttemptTimeStamp" as the property name, as opposed to "deliveryAttemptTimestamp" (note the lower case s) as in your sample. Is the live service returning a lower case s?

[markduregon]

Yes. As stated in the code example I sent you, the JSON in that is copied from an real event from the message queue. Can see you have created a PR to fix this. What would be the timeframe of a new package being available for a breaking change release?

[JoshLove-msft]

We are planning to ship a new version next week. Note this is not a breaking change, but rather a bug fix to deserialize the events correctly.