Priority annotations #274
Priority annotations #274
Conversation
| # @!attribute local? | ||
| # @return [Boolean] Whether the activity is a local activity or not. | ||
| # @!attribute priority | ||
| # @return [Priority, nil] The priority of this activity. |
There was a problem hiding this comment.
Can this ever be nil? (same for workflow info)
| :priority, | ||
| :versioning_override, |
There was a problem hiding this comment.
| :priority, | |
| :versioning_override, | |
| :versioning_override, | |
| :priority, |
Pedantic, but might as well keep in the same order as the parameters of the outer call
| input.static_summary, input.static_details, @client.data_converter | ||
| ), | ||
| header: ProtoUtils.headers_to_proto(input.headers, @client.data_converter), | ||
| priority: input.priority&._to_proto, |
There was a problem hiding this comment.
| priority: input.priority&._to_proto, | |
| priority: input.priority._to_proto, |
Same for everywhere else where priority actually can't be nil
| # The overall semantics of Priority are: | ||
| # 1. First, consider "priority_key": lower number goes first. | ||
| # (more will be added here later). | ||
| class Priority |
There was a problem hiding this comment.
I'm wondering if this should be a Data class (and get all of the goodies it provides). I think it makes sense like record did for .NET and @dataclass did for Python. Still will need much of what you have here (so after the Data.define, re-open the class Priority to add stuff).
| activity_id: nil, | ||
| disable_eager_execution: false | ||
| disable_eager_execution: false, | ||
| priority: Priority.default |
There was a problem hiding this comment.
Can we add the import to this file and to activity.rb? I know it doesn't make sense to add everywhere, but along with temporalio/client, these two are kinda "single require entry points" to the SDK.
| require 'temporalio/api' | ||
|
|
||
| module Temporalio | ||
| Priority = Data.define( |
There was a problem hiding this comment.
If you want to default a field for this you can still leave the initialize the way you had it in the class and just call super, e.g.
def initialize(priority_key: nil)
super
endBut requiring it is fine too.
There was a problem hiding this comment.
Yeah, honestly requiring it makes more sense
| class Priority | ||
| attr_reader priority_key: Integer? | ||
|
|
||
| def initialize: (?priority_key: Integer?) -> void |
There was a problem hiding this comment.
| def initialize: (?priority_key: Integer?) -> void | |
| def initialize: (priority_key: Integer?) -> void |
Pedantic though
| attr_reader last_result: Object? | ||
| attr_reader namespace: String | ||
| attr_reader parent: ParentInfo? | ||
| attr_reader priority: Temporalio::Priority? |
There was a problem hiding this comment.
| attr_reader priority: Temporalio::Priority? | |
| attr_reader priority: Temporalio::Priority |
| attr_reader heartbeat_details: Array[Object?] | ||
| attr_reader heartbeat_timeout: Float? | ||
| attr_reader local?: bool | ||
| attr_reader priority: Temporalio::Priority? |
There was a problem hiding this comment.
| attr_reader priority: Temporalio::Priority? | |
| attr_reader priority: Temporalio::Priority |
What was changed
Updated Core
Expose priority setting on workflow client & in child/activities launched from workflows
Why?
Priorities are cool!
Checklist
Closes [Feature Request] Support Priority Annotations #210
How was this tested:
Added integ test
Any docs updates needed?