fix: duration json type parsing fix

[Zylius]

What was changed

Added ability to parse DurationJsonType instance.

Why?

It no longer works, and if you need to pass it around to other services or save ActivityOptions somewhere, stuff breaks. I've made this as a check, so it should be BC, and messages using older format shouldn't fail during deployment.

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Zigmas Satkevičius seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Zylius]

Any ideas when this could be merged? 🥺

[roxblnfk]

Could you add a test case?
Or an instruction how to check the issue

[Zylius]

I cannot offer you tests, as they're functional and integrated within our system, but this snippet is basically already a test, just needs an assertion.

Without the code updated this will throw InvalidArgumentException

$type = new \Temporal\Internal\Marshaller\Type\DurationJsonType(new class implements \Temporal\Internal\Marshaller\MarshallerInterface
{
    public function marshal(object $from): mixed
    {
        return null;
    }

    public function unmarshal(array $from, object $to): object
    {
        return new \stdClass();
    }
});

$type->parse($type->serialize(1), null);

[Zylius]

Got a few free minutes, added a test :) without the fix it fails

[roxblnfk]

Do you need the ability to unmarshal ActivityOptions from the old JSON structure?
If yes, please provide a JSON payload example, and I will add it to the tests and include the necessary attributes to make it work.

[Zylius]

You saying where are more changes? I think only intervals changed

Here's the JSON payload exmple from 2.7.*

{
    "TaskQueueName": "test_queue",
    "ScheduleToCloseTimeout": 0,
    "ScheduleToStartTimeout": 0,
    "StartToCloseTimeout": 5000000000,
    "HeartbeatTimeout": 0,
    "WaitForCancellation": false,
    "ActivityID": "",
    "RetryPolicy": {
        "initial_interval": 0,
        "backoff_coefficient": 1,
        "maximum_interval": 0,
        "maximum_attempts": 4,
        "non_retryable_error_types": []
    }
}

Here is 2.8

{
    "TaskQueueName": "test_queue",
    "ScheduleToCloseTimeout": 0,
    "ScheduleToStartTimeout": 0,
    "StartToCloseTimeout": 5000000000,
    "HeartbeatTimeout": 0,
    "WaitForCancellation": false,
    "ActivityID": "",
    "RetryPolicy": {
        "initial_interval": {
            "seconds": 0,
            "nanos": 0
        },
        "backoff_coefficient": 1,
        "maximum_interval": {
            "seconds": 0,
            "nanos": 0
        },
        "maximum_attempts": 4,
        "non_retryable_error_types": []
    }
}

[roxblnfk]

It should be nanoseconds, right?

        "initial_interval": 0,
        "maximum_interval": 0,

[Zylius]

It should be nanoseconds, right?

        "initial_interval": 0,
        "maximum_interval": 0,

Yes the old format is in nanoseconds

[roxblnfk]

It's indeed an unusual case that DTOs of internal configurations are stored in the database or transferred between services.
However, it seems that such usage needs to be considered moving forward 🙂
SDK 2.8.2 has been released