Why don't timestamps from DF API match Storage Account timestamps

[gdodd1977]

I'm currently using the DF Api to grab orchestration information for a support UI that I have.

I noticed that when using a timer, the json returned from the Api shows the timestamp for the TimerCreated to be the same as TimerFired. Obviously this is incorrect. As well, when I look at them in the Storage Account, the TimeStamp column appears to be correct. Is there a bug in the DF Api that is making it so those values are not mapped properly? The TimerCreated timestamp matches, but the TimerFired is wrong.

See attached screenshots.

DF Api Json TimeStamps:

DF Storage Account Orch History TimeStamps:

[ConnorMcMahon]

This is expected behavior. For TimerFired events, they are actually created at the time when the Timer is created, with a value of FireAt for when we want the queue item to be visible. When the queue message is finally visible, an orchestrator will pick it up, process the event, and write it to the history table.

Timestamp is a reserved field in Azure Tables for when a row is created. Therefore, we cannot use that field to keep track of our own internal Timestamp value, which maps to the time that the history event was created. Therefore, we have a field called "_Timestamp" that actually maps to that value. You should find that the Timestamp on the history events returned by the Durable Functions API match with that column from the history table.

[gdodd1977]

Ok. That makes sense. Thanks for the information.

[andrewdmoreno]

@ConnorMcMahon Thanks for the explanation. Just to make sure we understand your response you are saying that in the rest api when we look at the data for a TimerFired event we will see the time that Timer is created in the Timestamp field. If we want to display, in a UI for instance, the time that the timer actually fired then we would have to fall back to using FireAt instead. Does this sound like a correct understanding?

[ConnorMcMahon]

@andrewdmoreno,

Thanks for asking the clarifying question.

In general, yes, looking at the FireAt field should give you an accurate time for when the timer actually fired.

There is the exception where your app has a large backlog of queue messages, and the TimerFired event took some extra time to be fired. The FireAt will reflect the time that the timer was scheduled to fire, not the time that it actually fired. Unfortunately, I don't think we currently expose a way to accurately retrieve the time that it was written to the history table (besides looking directly at the Timestamp field in Azure Tables). @cgillum, could you confirm that is the case?

I hope that answers your question!

[andrewdmoreno]

It does, thank you.

To add further context - we are attempting to show in our UI the timing of the orchestration events as they actually occurred in order for users to perform analysis and triage and be able to accurately correlate those times with times that other actions outside of the orchestration occurred. From what I am hearing it sounds like in this case the only fool proof way would be to have that Timestamp field from the Azure Table exposed some how, but that is not available at this time (will wait on confirmation from @cgillum).

For now we will update to use FireAt with the caveat that this may potentially not be correct.