Skip to content

Conversation

@cretz
Copy link
Member

@cretz cretz commented Jun 26, 2025

What was changed

  • Added Temporalio::Worker::IllegalWorkflowCallValidator for advanced call validation scenarios
  • Used advanced call validator to support Time.new in workflows when a positional argument is present
  • Used advanced call validator to support Time.iso8601 in workflows
  • CI fix that added one generated line to every proto API file (can ignore)

Checklist

  1. Closes [Feature Request] Time#iso8601 improperly considered illegal, look into excluding #272

@cretz cretz requested a review from a team as a code owner June 26, 2025 19:15
@cretz cretz changed the title More advanced illegal call validation Support certain Time calls in workflows with advanced validation Jun 26, 2025
Comment on lines 32 to 35
# When the xmlschema (aliased as iso8601) call is made, zone_offset is called which has a default parameter
# of Time.now.year. We want to prevent failing in that specific case. It is expensive to access the caller
# stack, but this is only done in the rare case they are calling this safely.
next if caller_locations&.any? { |loc| loc.label == 'Time.zone_offset' }
Copy link
Member

Choose a reason for hiding this comment

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

Do we? I mean, it's technically possible that a WFT isn't picked up across a year boundary. Not even that hard to have it happen if it's happening right around NYE UTC time.

IE: WFT timestamp is just pre-midnight, then replay happens after midnight and we end up assuming it's that time except a year forward.

Or, is what's actually happening here that the year has to be provided and this call is still made anyway? Not immediately obvious to me.

Copy link
Member Author

@cretz cretz Jun 27, 2025

Choose a reason for hiding this comment

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

Do we?

IMO yes. Here's what's happening...

A user reported they can't even parse an ISO8601 time in a workflow (totally deterministic) because of this limitation. The line of code at https://github.com/ruby/ruby/blob/5124f9ac7513eb590c37717337c430cb93caa151/lib/time.rb#L640 is triggering it. During ISO-8601 parse the Ruby code needs zone offset, but obtaining zone offset (https://github.com/ruby/ruby/blob/5124f9ac7513eb590c37717337c430cb93caa151/lib/time.rb#L82) asks for current year as a parameter default it doesn't even really use for these cases.

Copy link
Member

Choose a reason for hiding this comment

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

Ah, so, to clarify we're not actually getting the year from that, the call is just made anyway, even though we require the year to explicitly be set or set it ourselves?

Copy link
Member Author

Choose a reason for hiding this comment

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

Exactly. It's a default parameter evaluated at invocation that is not even used in this case.

@cretz
Copy link
Member Author

cretz commented Jun 27, 2025

Just added a CI fix that added a line to basically every API file and one rubocop disabling to an unrelated bridge file. Can ignore those.

@cretz cretz merged commit ee772d4 into temporalio:main Jun 27, 2025
7 checks passed
@cretz cretz deleted the advanced-illegal-time-check branch June 27, 2025 18:42
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.

[Feature Request] Time#iso8601 improperly considered illegal, look into excluding

2 participants