Final versioning API changes #285
Conversation
|
How does it get there? We need it in |
Sushisource
force-pushed
the
activity-ver-stamps
branch
from
ccb0b8f to
731bede
Compare
🤦 added |
|
Can you clarify the reasoning here? A workflow's compatibility is tied to the version it starts with (#284) right? Why do we need to record the version each task ran on? Is it just for user awareness? If so, is that worth adding this to so many history entries? |
Yes it's for user awareness. And users can choose to have activities run on the default version overall rather than the compatible version for the workflow. In either case, you can't deduce the exact version b/c you need to know what the default (overall or compatible set) was at the time the task was taken, which can't be determined easily. Given we're gonna limit ids to 255 characters, it seems a minimal cost. |
I don't see how that works given the client which completes those isn't tied to a version |
It responds on behalf of a worker |
But those are for async completions, which happen outside of a worker. |
| // a version compatible with the version that this workflow most recently ran on, if such | ||
| // behavior is possible. |
There was a problem hiding this comment.
WDYM by "if such behavior is possible"?
There was a problem hiding this comment.
It's not if, ex, you're starting an activity on a different queue which doesn't share your version
Sushisource
changed the title
|
@Sushisource make sure the next PR's title is "final final versioning API changes" |
* Add versioning stamp to activity task completions * Add to failed / cancelled events * Change use latest flag to use compat * Add use_versioning flag to capabilities message & comment wording updates
What changed?
Why?
Breaking changes