## Why?
`env.Context()` is deprecated.
NOTE: It cannot be deleted yet as `schedules_test.go` makes extensive
use of it still. That's a separate effort.
## What changed?
Support `MatchAll` in the UpdateOptions, Reset, and Unpause activity
APIs.
## Why?
MatchAll is the default set by the CLI so the current behavior has
broken the CLI and made reset silently succeed without actually
resetting any activities.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [X] added new functional test(s)
## Potential risks
Minimal, this fixes broken behavior.
## What changed?
Revert worker-heavy suites to legacy mode.
## Why?
There is a high rate of OOM killed CI jobs; the culprit are resource
leaks. But until we fix those, we need to lower the number of clusters
being started.
## What changed?
The Temporal worker service is now opt-in for `testcore.NewEnv`. Tests
that need scheduler / batcher / worker-deployment system workflows opt
in explicitly:
```go
env := testcore.NewEnv(t, testcore.WithWorkerService("V1 scheduler"))
```
`FunctionalTestBase`-based tests are unchanged.
## Why?
Profiling a 5-suite parallelsuite selection showed the system worker
service was responsible for ~55% of live memory and ~4s of test wall
time across all three persistence backends.
Measured impact on the selection (sqlite, locally):
| Metric | Before | After |
|---|---|---|
| Test wall (sqlite) | 33.0s | 29.1s |
| Live memory (inuse_space) | 200 MB | 89 MB |
Migrate `ActivityApiBatchUnpauseClientTestSuite` from testify suite +
`FunctionalTestBase` to `parallelsuite`, following the same pattern as
`ActivityAPIBatchResetClientTestSuite`.
## What changed and why?
### **Security**
- Check namespaces in batch workflow
([CVE-2026-5199](https://www.cve.org/cverecord?id=CVE-2026-5199), LOW)
## How did you test it?
- [x] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [x] added new unit test(s)
- [x] added new functional test(s)
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> Tightens namespace validation for privileged batcher activities to
prevent cross-namespace request spoofing; mistakes here could block
legitimate batch jobs or still leave gaps if other call paths use
unvalidated namespaces.
>
> **Overview**
> Adds strict namespace isolation checks to the batcher worker:
`BatchActivityWithProtobuf` now validates that `NamespaceId` *and* any
provided `Request.Namespace`/`AdminRequest.Namespace` match the worker’s
bound namespace, and consistently uses that bound namespace for
downstream frontend calls (including reset-by-type).
>
> Adds targeted tests: new unit tests to reject mismatched namespace
strings and to assert `startTaskProcessor` uses the worker namespace for
signals, plus a functional test ensuring a batch terminate in one
namespace does not affect workflows in another.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
3a526967f2. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
---------
Co-authored-by: Sean Kane <sean.kane@temporal.io>
## What changed?
Rename `FunctionalTestBase`'s `Worker` to `SdkWorker`.
## Why?
The new TestEnv uses `SdkClient/SdkWorker`; with this change the diff on
individual suite migrations is greatly reduced.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
commit 1: Ran `golangci-lint run --enable-only testifylint --fix
--build-tags test_dep ./tests/...`.
commit 2: Fixed lints that (1) exposed; such as deprecation lint
exclusions.
No other changes were made.
## Why?
Address testify lint issues in one go. This helps with migration to
TestEnv as it minimized the diff for these.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
## What
Used the `depguard` linter to prevent importing the package and modified
all uses of it.
Also fixed a bug in the membership code where we were not updating the
next page token:
https://github.com/temporalio/temporal/pull/8541/files#diff-985dd64ffa4c6bfe0248b982dc47439b725862baa3e1f2c559b7ff522bf21969R350
## Why?
From the package README in GitHub:
> This package now leverages the github.com/google/uuid package (which
is based off an earlier version of this package).
Also, there's no point in having two uuid implementations in the
codebase.
## Test
Added the invalid import and confirmed it works:
```
../service/frontend/admin_handler_test.go:13:2: import 'github.com/pborman/uuid' is not allowed from list 'main': Importing github.com/pborman/uuid is disallowed; use github.com/google/uuid instead (depguard)
_ "github.com/pborman/uuid"
```
## What changed?
Remove transient dependencies on persistence in the chasm package.
## How did you test it?
- [X] built
- [X] run locally and tested manually
- [X] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
Remove `BatchParams` to safely serialize proto -> json -> proto and add
a `BatchOperation` proto definition
## Why?
Remove custom serialization of proto for json safety.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [X] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## Potential risks
Could break batching backwards compatibility but tests should catch this
## What changed?
Refactor: use require instead of assert inside `EventuallyWithT`
callbacks.
## Why?
It turned out that `require` can be used inside `EventuallyWithT`
callback and it won't stop the test but exit current go routine only.
And every callback is executed inside separate goroutine.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
Refactor: remove `FunctionalTestSdkSuite` base struct and move SDK
client and worker to `FunctionalTestBase`.
## Why?
Many poller based tests use SDK client/worker for various operations. It
is much more convenient to have them defined in the top level base
class.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## 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 -->
Add functional tests for batch activity unpause.
## Why?
<!-- Tell your future self why have you made these changes -->
Part of activity API work.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
By adding tests.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
No risks.
## 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/`? -->
Not documented.
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
No.