Skip to content

Prevent None current_utc_time values when timestamps are really close to one another #246

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Dec 18, 2020

Conversation

davidmrdavid
Copy link
Collaborator

Addresses: #241

When orchestrator started events occur really close to one another, python's deterministic time API would sometimes return None. This PR is designed to match the JS implementation and instead return the previous timestamp

Copy link

@ConnorMcMahon ConnorMcMahon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's pretty close, but I have a few suggestions to make the code a bit more clear, at least from my perspective.

outputs.append(task2)
outputs.append(task3)

return outputs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good test, but you can make it even better by make sure that the value of current_utc_datetime is different for each of the calls you make. I wrote a similar test just the other day for the SQL backend and it uncovered a bunch of issues. Here is a reference to it if you think it might be useful to translate into Python: https://github.com/cgillum/durabletask-sqlserver/blob/a1a308c14b13ffca6a751f9fcdce111d55f40336/test/DurableTask.SqlServer.Tests/Integration/Orchestrations.cs#L114-L142

Copy link
Collaborator Author

@davidmrdavid davidmrdavid Dec 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I want to take a step back to sync on the context here though as I think our tests are validating different scenarios.

Mine makes sure that, in the case that we cannot distinguish the timestamps of two OrchestratorStarted events (maybe they occur too close to one another), current_utc_datetime would not be None. I was testing this specifically because, only in this scenario, current_utc_datetime would get explicitly assigned to None. In this case contrived case, current_utc_datetime would never update :P

I think yours is testing that the deterministic time API is correctly updating, right? I do think that's a good test, so I'll add it :) but I just wanted to make sure we were on the same page as to what I was trying to test for.

Copy link
Member

@cgillum cgillum Dec 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand it's beyond the scope of your PR, but given the fact that you decided to name this function generator_function_deterministic_utc_time I thought the suggestion for how you could also test for determinism might be appropriate. Of course, there would also need to be the None checks too since that's ultimately what you're trying to fix.

Copy link

@ConnorMcMahon ConnorMcMahon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Take two on leaving feedback.

if len(decision_started_events) != 0:
self.durable_context.decision_started_event = decision_started_events[0]

self.durable_context.current_utc_datetime = \

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this effectively doesn't do anything if len(decision_started_events) == 0. If that is the case, I would prefer we move this inside of the if block.

@davidmrdavid davidmrdavid merged commit 8409388 into dev Dec 18, 2020
@davidmrdavid davidmrdavid deleted the dajusto/no-none-timestamps branch December 18, 2020 00:33
@davidmrdavid
Copy link
Collaborator Author

Applied both of y'alls feedback. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants