Add a note that the worker command control queue uses
`TASK_QUEUE_KIND_WORKER_COMMANDS`.
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Adds generic `await.Rcv` and `await.Snd` helpers that bound blocking
channel operations by the test context and report closure or
cancellation clearly.
Replaces both previous helpers and existing unsafe channel rcv/snd
across tests.
## What changed?
Add a new `docs/architecture/circuit-breaker.md` file to explain the
circuit breaker component, and in particular how it relates to Nexus
requests.
The content was initially GenAI slop, with multiple revisions and
hand-crafted/artisanal edits to make it more concise and readable. There
are still some tell tale signs, e.g. "This key is the crux of the
isolation story." But to be honest, that seemed to help digest the
document. But I'm happy to revise as desired.
## Why?
This was something that I wanted to understand more deeply, and took a
non-zero amount of time to track down and understand some of the "how
and why" for Nexus.
## How did you test it?
NA, doc addition only.
## Potential risks
NA.
## What changed?
In `docs/architecture/history-service.md`, links pointed at
`service/history/workflow_task_handler_callbacks.go`. That file no
longer exists on `main` — its handlers were extracted into
`service/history/api/respondworkflowtaskcompleted/` (PRs #5902, #5904,
#5905, #5908, #5931, May 2024).
Repointed the dead links to the current code in
`service/history/api/respondworkflowtaskcompleted/api.go`, pinned to
commit `28dd23a` (current `main`), consistent with the doc's
pinned-commit convention:
**Line 171 — "Code entrypoints":**
| Anchor text | Old (`workflow_task_handler_callbacks.go`) | New
(`respondworkflowtaskcompleted/api.go`) |
| --- | --- | --- |
| handler | `handleWorkflowTaskCompleted` L371 | `Invoke` L110 |
| accumulates updates | `handleCommands` call L562 | `handleCommands`
call L416 |
| calls | `UpdateWorkflowExecutionWithNewAsActive` L690 |
`UpdateWorkflowExecutionWithNewAsActive` L623 |
**Line 310 — "Call sites":**
| Anchor text | Old | New |
| --- | --- | --- |
| `handleWorkflowTaskCompleted` → `Invoke` |
`workflow_task_handler_callbacks.go` L690 |
`respondworkflowtaskcompleted/api.go` L623 |
## Why?
The old blob links were stale link-rot pointing at code that has since
moved, so readers following them landed on a deleted file path on
`main`.
## How did you test it?
- [x] verified each new anchor resolves to the intended symbol at the
pinned commit (`git show origin/main:.../api.go` lines 110/416/623)
- [x] covered by existing tests (docs-only change)
## Potential risks
Docs-only change. Links are pinned to a commit SHA, so line numbers stay
stable, but they will drift from `HEAD` over time like the rest of the
doc's pinned links.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Gokhan Tekkaya
Co-authored-by: Claude Opus 4.8
Reworks CHASM scheduler's tasks to harden them against being silently
dropped, and fixes several edge-case bugs we've recently hit. Most of
these only surface in combination, so the fixes land together.
The logging here is just a few breadcrumbs — once the EventLog PR merges
I'll do a full logging/eventlogging pass, so don't read too much into
the individual log statements.
## What changed
### Generator
- `GeneratorTask` now keeps running while paused (advances the HWM,
updates `FutureActionTimes`, drops actions at the source) instead of
stopping — an improvement over V1.
- New `isManualOnly` / `isHeldOpen` helpers carve out schedules with no
automated wakeup source (empty spec, manual-only, pending backfill) so
the idle timer can't silently close them.
### Idle task
- Reworked around `isHeldOpen` plus an `.After()` deadline compare, so
sub-precision drift no longer drops tasks that should still fire.
- Fixes a non-monotonicity bug in `recentActions` (a closing workflow
could regress observed time).
### Invoker
- `ExecuteTask` captures the framework clock at read time and threads it
through `applyBackoff`, keeping `BackoffTime` consistent with
`LastProcessedTime` (no more wall-clock drift in tests/replay).
- `ProcessBufferTask` checks the catchup window before consuming a
`LimitedActions` slot.
- `recordExecuteResult` is idempotent per `RequestId`: a duplicate
`CompletedStart` / `RetryableStart` whose live entry already has a
`RunId` is dropped, without stomping `RunId`/`StartTime`/`HasCallback`
or rewinding `Attempt`/`BackoffTime`.
- `addTasks` is consolidated into a single-pass classifier; the
broadened re-arm gate fixes the stranded-retry bug.
### Backfiller
- `hasMoreAllowAllBackfills` was a misreading of the original code and
is gone — any pending backfill (not just `ALLOW_ALL`) holds a paused
schedule open while idling out.
- On completion, the backfiller revives the Generator so it can
re-evaluate idle/close eligibility.
## Tests
This PR carries only the minimal tests that go red→green with the fixes:
- **Functional** (`tests/schedule_test.go`): `TestPausedDropsCatchup`
and `TestFutureActionTimesAdvanceWhilePaused` — both fail on `main`; the
always-on Generator (advancing the HWM while paused) is what turns them
green.
- **Unit** (`chasm/lib/scheduler/`): targeted guards for each invoker
fix — idempotency, framework-clock, eligibility boundary, re-arm, and
catchup-before-limit — plus the modifications to pre-existing
idle/sentinel tests the rework requires.
Additional regression testing will live in a separate PR.
## Risks
This touches a fair amount of scheduler surface area, but the fixes are
individually validated and the diff is now mostly the rework itself.
## What changed?
Delete deprecated worker versioning docs
## Why?
We added this file when WV was in pre-release and did not have anything
in docs.temporal.io.
Now that it does and WV is in GA, we can delete it.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## Potential risks
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Low Risk**
> Low risk documentation-only change that deletes an outdated markdown
file; no runtime behavior is affected.
>
> **Overview**
> Deletes the deprecated `docs/worker-versioning.md` Worker Versioning
guide from the repository, removing outdated pre-release instructions
now that Worker Versioning documentation is maintained externally.
>
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
66a6997d42. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
## What changed?
Use the new dynamic config instead of leaving it as a placeholder and
update its documentation.
Also bumps the server version constant to `1.32.0`. This was supposed to
be done after the `1.31.0` release and was missed.
## Why?
Remove duplication as we migrate the code to the CHASM backed
implementation.
## Potential risks
This config is only relevant for external endpoints which are
experimental or older server versions, needs to be called out in the
release notes.
## What changed?
Introduces `common/testing/await`, a polling-based test helper that
replaces testify's `Eventually` / `EventuallyWithT`.
## Why?
From the [package
doc](https://github.com/temporalio/temporal/blob/stephanos/all-require/common/testing/await/await.go):
```
Improvements over testify's eventually functions:
- Misuse detection: accidentally using the real *testing.T (e.g. s.T() or
suite assertion methods) instead of the callback's collect T is a
common mistake. This package detects it and fails with a clear message.
- Safer bool predicates: unlike testify's Eventually, [RequireTrue] only
accepts func() bool, so returning false is the sole retry signal. If the
predicate accidentally marks the real test failed, it reports that
immediately instead of polling until timeout.
- Timeout-aware callbacks: callbacks receive a context derived from the
parent context and canceled when the await timeout or test deadline is
reached, so RPCs and blocking waits can exit instead of continuing after
the retry window has expired.
- Panic propagation: if the condition panics (e.g. nil dereference), the
panic is propagated immediately rather than being silently swallowed
or retried until timeout.
See https:github.com/stretchr/testify/issues/1810
- Bounded goroutine lifetime: each attempt completes before the next
starts, avoiding the overlapping-attempt data races and "panic: Fail
in goroutine after Test has completed" crashes seen with testify's
Eventually.
See https:github.com/stretchr/testify/issues/1611
- Deadlock detection: a condition that ignores t.Context() is abandoned
after a grace period, producing a clear "does it honor t.Context()?"
failure instead of hanging until go test -timeout.
- Condition always runs: testify's Eventually can fail without ever
running the condition due to a timer/ticker race with short timeouts.
This package runs the condition immediately on the first iteration.
See https://github.com/stretchr/testify/issues/1652
```
The upstream fix
([testify#1657](https://github.com/stretchr/testify/pull/1657)) aims to
address several of these but has been open since Oct 2024 without
merging.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)
## Potential risks
The biggest downside is that it adds more code that we own. But apart
from any unknown bugs, this package should rarely/never change.
## What changed?
Added a short protorequire package subsection to
docs/development/testing.md documenting protorequire.ProtoEqual and the
new protorequire.IgnoreFields option, with a minimal usage example.
## Why?
Follow-up to PR #9937. Without a doc entry, the new IgnoreFields helper
is undiscoverable and contributors will keep reaching for the verbose
cmp.Diff pattern.
## How did you test it?
- [X] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What
Adds an architecture doc for the worker commands framework — how
commands flow from history through matching to workers, and how to add
new command types.
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: Sean Kane <spkane31@gmail.com>
## What changed?
Added `parallelsuite` package to provide an alternative to testify's
suite.
**For reviewer: Use "Hide Whitespace" to make the diff smaller.**
## Why?
1. **Parallel by default**: all test methods and subtests run in
parallel automatically
2. **IDE support**: GoLand run gutters, navigation, and test discovery
work on Test* methods
4. **Misuse detection**: guard catches mixing assertions with Run(),
both directions, at runtime
5. **Type-safe subtests**: `s.Run` callbacks receive the concrete suite
type, so suite helpers are available
6. **No shared state**: each test method and subtest gets its own fresh
copy
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
Moved decision which d2 layout engine to use into file.
## Why?
Allows each file to pick the right layout engine for itself.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Cassandra 3.11 reached EOL in July 2023. Upgrade both development and CI
compose files to Cassandra 5.0 for current driver compatibility and
feature parity with ScyllaDB.
Changes:
- develop/docker-compose: cassandra:3.11 -> cassandra:5.0
- develop/github CI compose: cassandra:3.11 -> cassandra:5.0, increase
healthcheck retries from 30 to 60 (5.0 is slower to start)
- macOS docs: update to 5.0, remove stale ARM JNA workaround that is no
longer needed
## What changed?
Big change, but:
1. Cassandra 3.11 is End-of-Life.
2. Allowed me separately to change the Golang CQL driver to ScyllaDB's,
which doesn't support that EOL Cassandra anymore (my fault too, I
removed that support I think).
## Why?
If I wanted (and I do) to switch to ScyllaDB's GoCQL driver, I needed to
perform this change.
## 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)
## Potential risks
I also did not see any performance regression!
## What changed?
Functional tests write debug-level logs to a file rather than inline in
the job. Info and above are still visible and the debug logs are
available for download at the end of each test job.
## Why?
Debug level logs make parsing the functional test run logs very
difficult, sometimes too large to even download the logs. This makes
debugging flaky test runs even more difficult.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
- [X] manually verified in CI
## Potential risks
Minimal, debug logs are still available to download and parse. If there
are logs that are missing for debugging we should move those from
`debug` to `info` level in the future
## What changed?
Deleted `"system.enableNexus"`.
## Why?
Nexus has been GA since Dec 2024.
## 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?
Add a default 90s timeout to individual tests using the
`testcore.NewEnv` for setup. Tests should use the `context.Context`
returned from `testcore.NewEnv(...)` to fail early when a test exceeds
the timeout.
## Why?
Go only allows to set a timeout for an entire test run via `go test`,
but a single test case can make the entire run be stuck for the full
test timeout time. This change will make those tests exit early speeding
up the dev process.
## How did you test it?
- [ ] built
- [X] run locally and tested manually
- [X] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## Potential risks
Test change only, could introduce flakes if tests did not have previous
context timeouts.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> Touches shared test infrastructure and changes how contexts/timeouts
are created and propagated across functional tests, which could
introduce new test flakes or premature cancellations if timeouts are too
aggressive.
>
> **Overview**
> Functional tests created via `testcore.NewEnv` now get a *test-scoped*
timeout context (default **90s**, configurable via
`TEMPORAL_TEST_TIMEOUT` or per-test `testcore.WithTimeout`) that is
canceled on timeout and fails the test during cleanup.
>
> `testcore.NewContext` is updated to optionally derive from a parent
context, and key functional tests are migrated to pass
`s.Context()`/`env.Context()` into RPC calls and
`context.WithTimeout(...)` to respect cancellations. Linting/docs are
updated to discourage `context.Background()` in tests and document the
new timeout knob.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
98852a5e43. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
## What changed?
Re-does #9138 which was incidentally merged.
Include transient and speculative WFT events in
`GetWorkflowExecutionHistoryReponse` response, unless UI or CLI made
request.
* Adds `transient_or_speculative_events` back to
`GetMutableStateResponse`
* Reserve `transient_workflow_task` in `HisotryCOntinuation` token
* Add validation helpers
* Add query-compare-query for transient events at request start and end
Re-implements #7732
## Why?
Fix "premature end of stream" errors when workers request history after
cache eviction w/ transient/speculative workflow tasks present. This
adds transient & speculative WFT events in `GetWorkflowExecutionHistory`
(already in `PollWorkflowTask`). Worker cache eviction w/ speculative
workflow tasks causes the expected and actual event counts to be
different. #7732 passed transient events through continuation tokens,
which could become stale during pagination. This PR implements mutable
state querying at both start and end of pagination and compares
transient event IDs to detect if WFT state changed during pagination and
return a retryable error.
## 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)
## Potential risks
Same risks from #7732
## What changed?
Added `TEMPORAL_TEST_DATA_ENCODING` to change DataBlob encoding from
"proto3" to "json".
## Why?
Observability and debugging. The ability to see payloads decoded in
debugger and OTEL traces is valuable.
## 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
End users should never use this. The env var name therefore includes
`TEST_`.
## What changed?
Include transient and speculative WFT events in
`GetWorkflowExecutionHistoryReponse` response, unless UI or CLI made
request.
* Adds `transient_or_speculative_events` back to
`GetMutableStateResponse`
* Reserve `transient_workflow_task` in `HisotryCOntinuation` token
* Add validation helpers
* Add query-compare-query for transient events at request start and end
Re-implements #7732
## Why?
Fix "premature end of stream" errors when workers request history after
cache eviction w/ transient/speculative workflow tasks present. This
adds transient & speculative WFT events in `GetWorkflowExecutionHistory`
(already in `PollWorkflowTask`). Worker cache eviction w/ speculative
workflow tasks causes the expected and actual event counts to be
different. #7732 passed transient events through continuation tokens,
which could become stale during pagination. This PR implements mutable
state querying at both start and end of pagination and compares
transient event IDs to detect if WFT state changed during pagination and
return a retryable error.
## 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)
## Potential risks
Same risks from #7732
## What changed?
- Puts an upper bound on how many concurrent backfillers can be active
in a scheduler.
## Why?
- Prevents a case of unbounded growth.
## 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
- I've set too low a limit, and on rollout, we break someone expecting a
higher number of concurrent backfillers. But I'd be pretty surprised if
anyone has a use case for 100+ backfillers..
## What changed?
- Fix issues in architecture doc diagrams
## Why?
- Fix issues in architecture doc diagrams
## How did you test it?
- [x] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
Documentation Only. Update Nexus Readme to remove experimental language
and improve callback configuration recommendation.
## Why?
Nexus is Generally Available it is no longer experimental
Want to improve security posture for recommended configurations
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
---------
Co-authored-by: Roey Berman <roey@temporal.io>
Co-authored-by: Roey Berman <roey.berman@gmail.com>
## What changed?
1. add lint rule to not use FunctionalTestBase for new functional tests.
2. basic documentation for new `TestEnv` alternative approach
## Why?
Enforce policy for new tests while migrating existing ones.
## 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?
Migrated `TestWorkflowUpdateSuite` away from testify's `Suite`; enabling
parallel test execution.
**How it works**
- a test invokes `testcore.NewEnv(t)` to obtain a new `TestEnv`
- `TestEnv` sets `t.Parallel()` (_intentionally not giving a way to opt
out!_)
- `TestEnv` obtains a test cluster from `clusterPool` (_or blocks if all
are in-use right now_)
- env var `TEMPORAL_TEST_SHARED_CLUSTERS` controls size of the pool
- if a test relies on APIs like InjectHook, a dedicated cluster is used
to prevent overlap
- env var `TEMPORAL_TEST_DEDICATED_CLUSTERS` controls number of
dedicated clusters
**testify suites**
Existing test suites are limited by the same dedicated cluster pool to
prevent creating too many clusters.
**Database connections**
SQLite setup for TestEnv-based func tests (ie only
TestWorkflowUpdateSuite so far) has been changed to a file-based
approach since that supports much better concurrency due to its WAL that
an in-memory SQLite database does not support.
Connection limits for other databases were also raised due to connection
errors.
**Planned follow-ups**
- Migrating the other testify suites should be fairly straight-forward
with the use of AI agents.
- Reduce need for dedicated clusters by leveraging isolated
namespace-per-test more.
- Eliminate all `time.Sleep`s.
- Tweak test cluster pool behavior.
## Why?
1. **Local speedup**: benchmarks show a ~50% speed increase (36.1s →
16.6s) for `TestWorkflowUpdateSuite`.
5. **Namespace isolation**: every test runs in its own namespace. This
greatly reduces the risk of (accidental) collisions and also reduces the
need to craft unique identifiers such as for task queues and workflow
IDs.
6. **Deprecate testify suites**: Long-term strategy to remove use of
testify suites in functional tests (one reason being their inability to
run tests within a suite in parallel).
## 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 Issues
1. Logs become less useful since there is more interleaving of tests.
2. Higher resource consumption: it requires more concurrent connections
to databases and shows higher memory consumption (see 3 and 4). This
could cause some short-term instability on CI. Note that some other PRs
were merged to add mechanics for monitoring memory usage much better;
which will help here.
4. Until all functional tests are converted, there is an imbalance in
test cluster creation: migrated tests use the shared pool while current
tests create one cluster each. Especially given the fact that some tests
don't allow for test cluster sharing as they use non-parallelizable
actions such as `InjectHook` or dynamic config overrides. With some more
effort the number of these can be reduced.
7. Setup of test clusters was designed around the idea of short-lived
clusters, one per suite. But when re-using them for longer, some of the
assumptions don't hold anymore and increase memory usage. There's a band
aid in place to limit how often a test cluster can be used before it's
torn down. A long-term solution requires some design changes to how test
clusters are started/used/torn down.
8. If there are certain cross-namespace issues or bugs that affect
multiple tests, it might be harder to identify the root cause now.
However; the existing test re-runs should at least mitigate these
short-term.
---------
Co-authored-by: Dan Davison <dandavison7@gmail.com>
## What changed?
- Adds an up-to-date design doc on the CHASM scheduler.
- Recommend using GitHub's [View
File..](b8d2cc7361/docs/architecture/schedules.md)
link to see it rendered.
## Why?
- Suppose you put every engineer who was familiar with the CHASM
scheduler on a single bus...
---------
Co-authored-by: Vladyslav Simonenko <vlad.simonenko@temporal.io>
## What changed?
Changed use of `testhooks`'s `Set` to be runtime error instead of
compile time error.
It still ensures that the default impl (used in `go build` artifacts
without `test_dep` tag) is the noop impl.
## Why?
When running a functional test via plain `go test` it will fail, as the
`test_dep` build flag is required. It is required to prevent
accidentally using the default/noop implementation of the `testhooks`
package which allows injecting custom behavior into production code from
tests.
But requiring `test_dep` to run any test adds friction: CLI invocations
need to specify it manually, editor setups need to be adjusted, AI
agents need to be instructed. That's a high price to pay for a test
helper that is used fairly sparsely.
## How did you test it?
- [ ] built
- [x] run locally and tested manually
- [x] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)
Functional test without testhook:
```
% go test ./tests -run "OwnershipLostErrorSuite" -count=1 .
ok go.temporal.io/server/tests 7.062s
```
Functional test with testhook and build tag:
```
% go test ./tests -run "TestUpdateWorkflowSuite" -tags test_dep -count=1 .
ok go.temporal.io/server/tests 36.975s
```
Functional test with testhook but no build tag:
```
% go test ./tests -run "TestUpdateWorkflowSuite" -count=1 .
...
noop_impl.go:39: test panicked: testhooks.Set called but TestHooks are not enabled: use -tags=test_dep when running `go test`
goroutine 33293 [running]:
runtime/debug.Stack()
...
FAIL
FAIL go.temporal.io/server/tests 57.128s
FAIL
```
## What changed?
Context cancelations are getting incorrectly translated to `Unavailable`
service errors, which lead to Visibility Availability Alert false
positives.
This code change adds branches to check context error types before
casting to the resulting `serviceerror` for both ElasticSearch and SQL
visibility stores.
## Why?
Separate client and service side errors.
## 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)
---------
Co-authored-by: Rodrigo Zhou <rodrigo.zhou@temporal.io>
## What changed?
- Reduced log level of failed Nexus requests originating from worker to
debug level.
- Updated CONTRIBUTING.md and testing.md to reflect current status and
to include IDE debugging.
- Added failure source setting to worker in nexus handler when dispatch
context deadline exceeded.
## Why?
- Today we log an error for every request, which pollutes server logs
and is inconsistent with activity and workflow task failures. We don't
want to completely lose visibility into these errors since some of the
errors can originate internally and may be tricky to debug.
- We've missed spots in setting worker failure source in the nexus
handler
- The docs are a bit outdated, and it's also helpful to have IDE
specific debugging instructions.
## 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)
## Ticket
[OSS-4548](https://temporalio.atlassian.net/browse/OSS-4548)
[OSS-4548]:
https://temporalio.atlassian.net/browse/OSS-4548?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
---------
Co-authored-by: Roey Berman <roey.berman@gmail.com>
## What changed?
Improve the error message for an Update that is aborted by a closing
workflow.
## Why?
To make it easier for users to understand what happend; and for devs to
debug it easier.
## 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
Very low as the service error _type_ is still the same (NotFound).
## What changed?
Workflow Update: update doc to reflect recent changes in #7296.
## Why?
Keep internal doc up to date.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
<!-- Describe what has changed in this PR -->
Increased OTEL_BSP_SCHEDULE_DELAY from 0 to 100ms.
## Why?
<!-- Tell your future self why have you made these changes -->
Zero is too aggressive and leads to too much CPU usage.
## 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) -->
## What changed?
<!-- Describe what has changed in this PR -->
Fixed code coverage reporting.
## Why?
<!-- Tell your future self why have you made these changes -->
We haven't reported code coverage in over a year.
It stopped working when we moved away from Buildkite.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Checkout https://app.codecov.io/gh/temporalio/temporal
There's no data for main ("master") yet, though, until we merge.
I'll also leave the README coveralls badge there for now.
## 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 -->
## 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) -->
## What changed?
<!-- Describe what has changed in this PR -->
Workflow Update: fix doc on when `WorkflowUpdateAbortedErr` is returned.
## Why?
<!-- Tell your future self why have you made these changes -->
Make doc in-sync with code.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
N/A
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
N/A
## 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/`? -->
It is it.
## 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.
## What changed?
<!-- Describe what has changed in this PR -->
Remove `key` parameter from `testvar` methods.
## Why?
<!-- Tell your future self why have you made these changes -->
It turn out to be confusing for people on how to use optional `key`
parameter. @bergundy got a great idea to remove this parameter and use
different instance of `tv` when more than one entity is needed.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Run all tests. Refactoring affects test code only.
## 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/`? -->
Yes, updated testing 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) -->
No.
## What changed?
<!-- Describe what has changed in this PR -->
Added new taskpoller to project's testing guidelines.
## Why?
<!-- Tell your future self why have you made these changes -->
To recommend this behavior to newcomers.
## 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) -->
