Durable functions reduce ISO8061's precession if milli second have zero as digit values

[MuhamedSalihSeyedIbrahim]

Description

Azure Durable function reduce precession of ISO 8061 date string format.
when ever the ISO date string passed to activity function its converted from higher precession to lower precession
YYYY-MM-DDTHH:MM:SS.SSSZ (actual format ) converted to YYYY-MM-DDTHH:MM:SSZ (lower precession format ) in case millisecond are present as zeros.

Eg:

1. 2021-03-23T00:11:50.111Z // actual format this is not affected.
2. 2021-03-23T00:11:50.000Z ----> 2021-03-23T00:11:50Z // affected and converted into lower precession string

Expected behavior

we are passing ISO 8061 date string with precession of millisecond up to 3 digit values it should be preserved across the trigger , orca and activities etc..,

Actual behavior

when orchestrator or activity receive a ISO 8061 date string some how its precession is lowered in case if the millisecond parts have zero so the precession is decreased to second level

Relevant source code snippets

client function:

const df = require("durable-functions");

async function DHT(context, req) {
const client = df.getClient(context);
const instanceId = await client.startNew(req.params.functionName, undefined, {
date: "2021-06-21T00:00:00.000Z",
});

context.log(Started orchestration with ID = '${instanceId}'.);

return client.createCheckStatusResponse(context.bindingData.req, instanceId);
}

module.exports = DHT;

orchestrator:

const df = require("durable-functions");

const DO = df.orchestrator(function* (context) {
const outputs = [];

const { date } = context.df.getInput();
console.log(date);
// Replace "Hello" with the name of your Durable Activity Function.
outputs.push(yield context.df.callActivity("DA", date));
outputs.push(yield context.df.callActivity("DA", date));
outputs.push(yield context.df.callActivity("DA", date));

// returns ["DA Tokyo!", "Hello Seattle!", "Hello London!"]
return outputs;
});

module.exports = DO;

---

Activity:

async function DA(context) {
console.log(Hello ${context.bindings.name}!);
return Hello ${context.bindings.name}!;
}

---

Known workarounds

we added some 1 millisecond or replace last 0 in millisecond to one and we could observe the precession is preserved

App Details

• Durable Functions extension version (e.g. v1.8.3) :1.8.7 (which comes with azure function extension bundle [1.*, 2.0.0))
• Azure Functions runtime version (1.0 or 2.0) :3.0 (2.0)
• Programming language used :NodeJS

Screenshots

If deployed to Azure

we don't want to share app detail but I have shared the sample app complete code I hope that can reduce the issue.

[davidmrdavid]

Hi @MuhamedSalihSeyedIbrahim,

Thanks for reaching out! I see that you're using extension bundles in the V1 range. Are you able to reproduce this behavior in the V2 range? That is, in range: [2.*, 3.0.0)? We recently implemented various serialization fixes in the V2-ranged version of the durable-extension, so there's a good chance this issue is fixed there. Please let me know! If not, I'm happy to dive deeper! Thanks!!

[MuhamedSalihSeyedIbrahim]

@davidmrdavid ok sure will check that and let you know.

Can you pls confirm changing bundle version to v2 does it affect our other trigger binding like blob trigger
(Mean to ask if there are breaking changes in implementation respect to bindings and others)?

[MuhamedSalihSeyedIbrahim]

@davidmrdavid
Is there way to install 2x bundle? With some command in non .net code??

I have experimented with just changing the version in host.json

I still can see the date issue
At activity level

FYI one thing i noticed is, I can have proper date till orchestrator but in v1 thats not the case

PFA:

[davidmrdavid]

Hi @MuhamedSalihSeyedIbrahim,

Thanks for your quick responses!

With respect to installing the V2 version of the bundles, changing the host.json string should suffice. So, it appears to me, that you've done it correctly :) .

Just for clarity, am I right in understanding that, after changing your extension bundles version to be in the V2 range, you no longer see a loss of precision for this date-formatted-string input in the orchestrator? Now, you're only seeing precision loss in the activities, correct? Thanks!

[davidmrdavid]

Additionally, what version of the durable-functions npm package are you using? I'm asking because I'm trying to reproduce this locally and, at least when using the V2 bundles and the latest version of the durable-functions npm package, I don't see this precision loss.

[MuhamedSalihSeyedIbrahim]

@davidmrdavid yes I observed that behaviour only on activity with v2 bundle (so fyi i just attached the screen shot)

[MuhamedSalihSeyedIbrahim]

^1.4.6 durable function npm package version is the one i am using.

I share my sample code already.

And if you don't mind to share your sample code, i shall try it in my local or dev server and revert back with my result in this issue thread

[davidmrdavid]

Hi @MuhamedSalihSeyedIbrahim,

Of course. I'm attaching a zip of my project file to reproduce this issue. Please find it below:

js-dates.zip

I'm also attaching a picture of the output I'm seeing, note how the three 0's at the end are preserved in the logged/printed statements:

Please let me know if there's something off about my reproducer! Thank you :)

[MuhamedSalihSeyedIbrahim]

Hi @MuhamedSalihSeyedIbrahim,

Of course. I'm attaching a zip of my project file to reproduce this issue. Please find it below:

js-dates.zip

I'm also attaching a picture of the output I'm seeing, note how the three 0's at the end are preserved in the logged/printed statements:

Please let me know if there's something off about my reproducer! Thank you :)

In orcha
instead of -> outputs.push(yield context.df.callActivity("Hello", date )); // direct date passing as param (not finding the issue)
use this -> outputs.push(yield context.df.callActivity("Hello", { date })); // passing date as a obj prop(finding issue here)

[davidmrdavid]

Thanks @MuhamedSalihSeyedIbrahim,

I'm able to reproduce this issue now! I'll file this as a bug and start an investigation in a few days. Thank you!
In the meantime, as a temporary workaround, adding an extra alphabetical character should suffice to preserve the precision. This way, the framework won't accidentally parse it as a Date and instead preserve it as a proper string, as it should.

I'll keep you updated with our progress. Until then, let me know if this workaround works for you in the meantime! Thanks again :)

[MuhamedSalihSeyedIbrahim]

We already adding 1 milli second to avoid this issue
but as our param to orcha and activity becoming complex structures with lot of date string involved we will be reaching the limit soon to process it and add milli second to preserve the date precession manually.

For now its fine! But awaiting for your response