We need to do backwards compatibility for this one.

Hi any progress on this one?

Hi any progress on this? I have added this in Cadence long time ago. You may copy some code from it which can make it easier: cadence-workflow/cadence-java-client#650

Not yet. It's a pretty tricky task to do because of the backward compatibility and the fact that the Version State Machine is one of the trickiest ones already. It's on my radar though and I will prioritize it when I get a chance.

Hi, is there any update on this?

I'm also curious, I tried to query the TemporalChangeVersion and nothing showed up in the TemporalUI because I used the JavaSDK to do a patch on the workflow.

@Quinn-With-Two-Ns is there an alternative workaround you might recommend to discover versions of WF so that users can more easily remove chunks of code with confidence?

@Quinn-With-Two-Ns is there an alternative workaround you might recommend to discover versions of WF so that users can more easily remove chunks of code with confidence?

Try this design pattern https://medium.com/@qlong/how-to-overcome-some-maintenance-challenges-of-temporal-cadence-workflow-versioning-f893815dd18d

Also this sample temporalio/samples-java#664

Thanks @longquanzheng and @Quinn-With-Two-Ns for the references!

Hi there! This issue has been open for quite a long time. Any updates on prioritization?

Also, I wanted to call out that, at Netflix, we ran into a problem with a similar solution to the sample shared above when removing code paths for old versions, because the call to Workflow.upsertTypedSearchAttributes writes an event to the workflow history, so removing it is a backwards-incompatible (aka non-deterministic) workflow change. So if you have long-running workflows, even with continue-as-new, chances are you'll run into a NonDeterministicException when doing deployments (which we tend to do frequently), which then gets the workflows stuck.

This issue is a high priority for us, but some bugs related to GetVersion needed to be resolved first. This is not a trivial feature to implement due to backward compatibility and the complexity around the versioning state machine. I hope to make some progress on this soon.

Thanks for the update, @Quinn-With-Two-Ns. Glad to hear you're prioritizing improvements around this. Out of curiosity, can you please elaborate a bit on the backward compatibility and complexity if this is already supported in the Go SDK? I assume versioning is ultimately implemented at the low level of the protocol/server, so what's special about Java that makes it more difficult to expose the same feature there?

P.S. The original issue proposes a specific solution, which is to use search attributes. Personally, I don't care as much about the implementation detail, so long as there's a way for us to query for what workflows have what changes/versions enabled. For example, if there was a way to query the data that's already recorded in the workflow history as in the example below, that would be fine with me.

Looks like the version is recorded using the concept of a "marker" -- if there was a way to query for markers, we'd be set. 🙂

I assume versioning is ultimately implemented at the low level of the protocol/server...

No, versioning is implemented entirely in the SDK and the implementation in Go is very different then Java so there is no shared logic. Every SDK uses search attributes here so the Java SDK would as well

@Quinn-With-Two-Ns Thanks for the context.