## What changed?
- Updated worker versioning inheritance logic for workflow chains
(parent-child and continue-as-new)
- Replaced deprecated pinned_deployment_version with new
inherited_pinned_version field in workflow execution
- Handled versioning inheritance for retry and cron workflows
- Allow cross-task-queue CaN and Child pinned version inheritance if new
task queue is in the inherited version
## Why?
- Improves versioning behavior consistency across workflow chains by
properly inheriting versioning info from parent/previous runs
- Removes deprecated fields and aligns with new versioning API design
- Fixes edge cases in versioning inheritance for retry and cron
workflows
Basically, we want `PINNED` behavior to carry through parent child
chains, and across the CaN boundary, so that we can roll out a new
behavior for Trampolining in the future, which will not be inherited
across the CaN boundary.
## How did you test it?
- [x] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [ ] added new unit test(s)
- [x] added new functional test(s)
## Potential risks
Could break history :P
## What changed?
Change version string to a struct
- The worker management workflows have not changed in this PR, instead,
the new inputs are converted to the old inputs when they come in, and
the responses are filled in to have both the old and new fields
- Only the new way to specify version transition is stored in MS, but
both are populated on read
- Change VersioningOverride so that we can safely specify multiple types
of pinned override in the future
- Store only the new fields, return the old fields on read.
## Why?
So that we don't have to rely on the string representation of a version,
and to make way for more types of PINNED.
## How did you test it?
- [x] built
- [x] run locally and tested manually
- [x] covered by existing tests
- [x] added new unit test(s)
- [x] added new functional test(s)
## Potential risks
This could theoretically break how workflow execution versioning info
and old versioning overrides are handled when they are read, how
pinned-ness is calculated, etc. The functional tests in
versioning_3_test.go test for this, and they revealed mistakes I had
made, which means we know those code paths are executed.
I did not change anything in the Deployment Manager workflows, so this
PR does not risk breaking those workflows via an incompatible change.
Tests in DeploymentVersionSuite guard against the risk of older SDK
users not seeing the fields they expect.
## What changed?
<!-- Describe what has changed in this PR -->
Remove license header from every file. Because it is really hard to
follow in this PR here is the summary:
1. License header is removed from all `.go` and `.proto` files
:fireworks::fireworks:🎆.
2. `LICENSE` file in the root directory has only Temporal and Uber
copyrights.
3. 5 other `LICENSE` files added to the packages which have copyrights
different from Temporal and Uber: Datadog, Xargin, "Mat Ryer, Tyler
Bunnell and contributors".
4. `license_file` flag is removed from all code generation tools.
5. `copyright_file` flag is removed from `go:generate mockgen`
directive.
6. All copyright related targets are removed from `Makefile`.
7. Updated Temporal copyright year to 2025 everywhere.
## Why?
<!-- Tell your future self why have you made these changes -->
I double checked with legal department that it is not needed to have
license header in every file. One file per repo is enough. I put all
copyrights to the root `LICENSE` file and removed header from all other
files. Also updated tools and `Makefile`.
## What changed?
<!-- Describe what has changed in this PR -->
Syncing TQ User Data for all types of a single TQ name at once to reduce
the SetCurrent and SetRamping latency and flakiness of tests.
## Why?
<!-- Tell your future self why have you made these changes -->
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
---------
Co-authored-by: Carly de Frondeville <carly.defrondeville@temporal.io>
## What changed?
<!-- Describe what has changed in this PR -->
Child workflows start in parent's pinned Worker Deployment Version.
## Why?
<!-- Tell your future self why have you made these changes -->
So user do not have to worry about interface compatibility between
pinned parents and children.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Added new tests.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
Add root workflow execution to mutable state.
The root workflow execution is defined as follows:
1. A workflow without parent workflow is its own root workflow.
2. A workflow that has a parent workflow has the same root workflow as
its parent workflow.
Examples:
- Scenario 1: Workflow W1 starts child workflow W2, and W2 starts child
workflow W3.
- The root workflow of all three workflows is W1.
- Scenario 2: Workflow W1 starts child workflow W2, and W2 continued as
new W3.
- The root workflow of all three workflows is W1.
- Scenario 3: Workflow W1 continued as W2.
- The root workflow of W1 is W1 and the root workflow of W2 is W2.
## Why?
<!-- Tell your future self why have you made these changes -->
We want to add this information to Visibility, so it can list all
workflows based on the root execution.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Changed existing tests to check the root workflow execution is being
correctly set.
- Checked history event in the start workflow, start child workflow and
continue as new workflow.
-
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
I've upgraded the version of our Go API in order to allow invalid UTF-8
data in our proto strings.
Please review
5cf979058d
only
## Why?
The version of gogo/protobuf we used allowed invalid UTF-8 in strings
which is a violation of the proto3 spec. We were unaware of this until
our new google/protobuf based structs began failing to deserialize data
we'd used previously
## How did you test it?
I added a new end-to-end test to verify that we can create, describe,
and delete a namespace that contains invalid UTF-8 in multiple
attributes
## Potential risks
This is lower risk than commits prior to this as temporal DBs may
already contain invalid UTF-8 data
## Documentation
I adjusted our docs to mention this behavior and the `protolegacy` tag
## Is hotfix candidate?
Yes: this will be going out as part of our 1.23.0 release. In fact, the
release is blocked on it!
---------
Co-authored-by: David Reiss <david@temporal.io>
## What changed?
I replaced protoc.sh with
[protogen](https://github.com/temporalio/api-go/pull/139)
## Why?
I've copied some variant of this protoc.sh tool into three repos now.
This is unsustainable, so I've added a little build tool to api-go that
will handle proto generation and post-processing for us.
## How did you test it?
[I ran `make proto` in the PR stacked on this
one](https://github.com/temporalio/temporal/pull/5211)
## Potential risks
None
## Is hotfix candidate?
No
**What changed?**
I rebuilt all proto files and bumped the version of our protoc plugin
**Why?**
So as to not pollute the PRs of others
**How did you test it?**
CI
**Potential risks**
None
**Is hotfix candidate?**
No.
**What changed?**
I added the magic MIT License header to all proto files and regenerated
the code
**Why?**
Turns out we didn't include the header our licensegen script checked
for, so when the new protoc plugin prepending the license our licensegen
script would prepend it a second time
**What changed?**
gogo/protobuf has been replaced with Google's official go compiler.
**Why?**
gogo/protobuf has been deprecated for some time and the community is
moving on, building new tools (like vtproto) atop google's v2 compiler.
**How did you test it?**
`make test`
**Potential risks**
1. The change from embedded gogo-generated-structs to
google-generated-pointers-to-structs created a risk of nil pointer
exceptions. I've fixed all the ones our tests found but it's possible
there are more lurking in the new code.
2. This change may cause our performance to decrease. Certainly
encoding/deconding of proto objects will become slower, but the overuse
of pointers by the google compiler may negatively affect our overall
performance. We'll need to keep an eye on the GC stats
3. This breaks the HTTP API. We will not support [shortand payload
encoding](https://github.com/temporalio/proposals/blob/master/api/http-api.md#payload-formatting)
in this first pass; that will come once this initial work is in testing.
**Breaking changes for developers**
- `*time.Time` in proto structs will now be
[timestamppb.Timestamp](https://pkg.go.dev/google.golang.org/protobuf@v1.31.0/types/known/timestamppb#section-documentation)
- `*time.Duration` will now be
[durationpb.Duration](https://pkg.go.dev/google.golang.org/protobuf/types/known/durationpb)
- V2-generated structs embed locks, so you cannot dereference them. `go
vet` will scream at you about this. If you need a copy, use
`proto.Clone`.
- If the performance of this sucks then I will either update our code
generator to add shallow-clone methods or hand-roll the ones we need
- Proto enums will, when formatted to JSON, now be in
`SCREAMING_SNAKE_CASE` rather than `PascalCase`. We decided (in
discussion with the SDK team) that now was as good a time as any to rip
the bandage off.
- Proto objects, or objects embedding protos, cannot be compared using
`reflect.DeepEqual` or _anything_ that uses it. This includes `testify`
and `mock` equality testers!
- You will need to use the `common/testing/protorequire`,
`common/testing/protoassert`, or `common/testing/protomock` packages
instead. I've implemented proto-compatible matchers and assertions there
for all cases I've encountered
- If you need `reflect.DeepEqual` for any reason you can use
`go.temporal.io/api/temporalproto.DeepEqual` instead
Note that history loading will not be impacted by the JSON changes: I
rewrote history loading to dynamically fix incoming history JSON data
(like all our other sdks); you can find this code in [my fork of our go
API](https://github.com/tdeebswihart/temporal-api-go/blob/master/internal/temporalhistoryv1/load.go)
alongside its tests.
**🚨Sharp Edges Introduced🚨**
Beware `*timestamppb.Timestamp.AsTime()`. If you need to extract a time
value from a proto time (timestamppb) **always** make sure to check
whether it's nil first. When the proto object is `nil` `AsTime()` will
return a non-zero time at the proto epoch: UTC midnight on January 1,
1970.
I've made this mistake multiple times during this transition and each
time it's been a pain to debug
**Is hotfix candidate?**
No.
