tests - #10695
Closed
davidporter-id-au wants to merge 11 commits into
Closed
Conversation
Prepare release branch: - Overwrite governance files - Update dependencies --------- Co-authored-by: Temporal Release Bot <release-bot@temporal.io>
…)" (temporalio#10553) Reverts temporalio#9961 for the cloud/v1.32.0-157 release branch. The skip-if-clean optimization in `closeTransactionSerializeNodes` introduced a bug where a parent component with unchanged Data bytes (e.g. `*emptypb.Empty`) would have its `LastUpdateVersionedTransition` suppressed. This left the component absent from `UpdatedChasmNodes`, so the standby's cached Go map (e.g. `w.Callbacks`) was never invalidated — causing `syncSubComponents` to tombstone newly-replicated CHASM Map children as orphans after a namespace handover. This was confirmed by bisect to be the root cause of the CHASM migration pipeline failure (missing Nexus operation completion delivery after namespace handover). See companion PR against main: #<main-pr-number> **Test plan** - Unit tests pass - Re-run CHASM migration nightly pipeline Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…0605) (temporalio#10617) `getCompletionCallbacksAsProtoSlice` now returns the callbacks' original request IDs alongside the `commonpb.Callback`, and the continue-as-new paths preserve them when re-registering the inherited callbacks on the new run. When a workflow continues-as-new, its completion callbacks are propagated to the new run via the `WorkflowExecutionStarted` event's CompletionCallbacks. That public type has no request-ID field, so the request ID was dropped and the new run re-stamped each inherited callback with its own start request ID. Completions that are validated by request ID then break. Concretely, when a CHASM scheduler-started workflow continues-as-new, the completion callback (`temporal://internal`) fires with the regenerated request ID; `Scheduler.HandleNexusCompletion` looks the action up by request ID via `Invoker.runningWorkflowID`, finds no match, and silently drops the completion — so the action and LastCompletionResult never propagates. - [x] built - [x] covered by existing tests - [x] added new functional test(s) - New functional test `TestScheduleCHASM/TestScheduledWorkflowContinueAsNewCompletion`: a scheduled workflow continues-as-new once then completes; asserts a later action observes a non-empty LastCompletionResult. Fails without thns dropped) and passes with it (~4s).
Backports a series of scheduler changes onto `cloud/v1.32.0-157`. Cherry-picked in chronological order from `main` (applied cleanly as a stack; no conflicts when ordered correctly). ### Commits (oldest → newest) | Upstream PR | Description | |---|---| | temporalio#10348 | Add percentage-based dialup for creation and migration | | temporalio#10439 | Adds scheduleIdleCloseTime | | temporalio#10517 | Plumb Tweakables through Scheduler's CHASM context values, use in EventLog | | temporalio#10369 | Rework and instrument CHASM scheduler tasks, add coverage | | temporalio#10530 | Log decisions and task events via the EventLog | | temporalio#10505 | Add a flag to allow only migration of schedules without running workflows | | temporalio#10406 | Adding scanner for invariants for schedules v2 | | temporalio#10503 | Add scheduler observability metrics for missed actions | Note: temporalio#10390 (next-action-time) was already present on the target branch and is omitted. Builds clean (`go build` over affected packages). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Lina Jodoin <lina.jodoin@temporal.io> Co-authored-by: Alex Stanfield <13949480+chaptersix@users.noreply.github.com> Co-authored-by: Sean Kane <spkane31@gmail.com>
…alio#10620) ## Summary Cherry-picks from main into `cloud/v1.32.0-157` to land the testrunner timeout fix plus the test-instability fixes called out in the OSS testrunner incident thread. ## Cherry-picks (chronological) | Order | PR | Notes | |------|----|-------| | 1 | temporalio#10355 — Fails tests that soft assert on shared clusters | Brought in as a dependency for temporalio#10593. `tests/task_queue_test.go` conflict dismissed (test isn't on the `newTestEnv`/`WithDisableTestloggerFailure` pattern yet on 157) | | 2 | temporalio#10587 — Fix failures after parallelsuite migration | Only `priority_fairness_test.go` hunk landed; `dlq_test.go` + `links_test.go` conflicts dismissed since those suites aren't on parallelsuite yet on 157 (per Stephan's guidance) | | 3 | temporalio#10590 — Fix xdc redirection policy wiring | Clean | | 4 | temporalio#10593 — Fix cluster pool max-usage recycling | Clean (after temporalio#10355) | | 5 | temporalio#10584 — testrunner: exit non-zero when total-timeout fires | Testrunner core + post-test-reporting guardrail + schedule_test skip applied. The `tests/activity_standalone_test.go` skip was dropped because the SAA test it skips (`PerExecutionCapNotEnforcedWhenLinksWillBeDropped`, added June 4) isn't on 157 | ## Manual resolution Extra fix on top of the cherry-picks: a small manual commit updates 4 string literals in tests/signal_with_start_from_workflow_test.go from "WorkflowService" to workflowservicenexus.TemporalAPIWorkflowserviceV1WorkflowService.ServiceName. The server-side Nexus registration on 157 already uses the qualified constant, so these tests were silently failing on 157 (hidden by the testrunner bug that temporalio#10584 fixes) ## Not included - temporalio#10592 (SQL persistence test IDs) — dropped per release-eng decision; its dependencies (temporalio#10458/temporalio#10463 testcore.NewEnv migrations) are not on 157 - temporalio#10595 (shorten deployment IDs) — dropped per release-eng decision; depends on temporalio#10510 which is the parent test and is already on 157 --------- Co-authored-by: samm <sam.mathis@temporal.io> Co-authored-by: Stephan Behnke <stephanos@users.noreply.github.com>
## What changed? Batch worker rate limiter will dynamically pick up changes to dynamic config, allowing fine tuning of the rate limiter. ## Why? Fine tuning rate limiter ## 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 Minimal, already backported
… to cloud/v1.32.0-157 (temporalio#10625) Two scheduler follow-up fixes backported onto `cloud/v1.32.0-157`, cherry-picked from `main` in chronological order. These build on PR temporalio#10608 (already merged into this release branch), which carried the scanner (temporalio#10406) and nextActionTime search attribute (temporalio#10390). The reason this is in a followup set of changes is that it was approved after the earlier set. The Scanner PR refactors the configuration shape (as per review request) and it'd be nice to avoid rework for the dynamic config to get it in the newer format before rollout. The Frontend changes are to allow for the use and querying of the `nextFireTime` search attribute by CLI users. ### Commits (oldest → newest) | Upstream PR | Description | |---|---| | temporalio#10606 | Search-attribute `nextActionTime` is queryable; fixes/splits out the functional test | | temporalio#10596 | Scanner for invariants — follow-up |
…2.0-157 (temporalio#10631) Backports PR temporalio#10611 onto `cloud/v1.32.0-157`, cherry-picked cleanly from `main` (squash commit `7da25f311`). ### Commit | Upstream PR | Description | |---|---| | temporalio#10611 | [Scheduler] Add `RunningWorkflowCount`/`BufferedStartsCount` to visibility | Co-authored-by: Lina Jodoin <lina.jodoin@temporal.io>
…oralio#10624) ## What changed? Backports temporalio#10546 to `cloud/v1.32.0-157`. Adds a host-level rate limiter for controlling RPS of admin batch operations across all namespaces and admin batch workflows. ## Why? Patch the 1.32.0-157 release so admin batch operations can have their total RPS controlled at the host level. Clean cherry-pick (`-x`) of the squashed commit `6e424ea`, rebased on top of the temporalio#10533 backport (temporalio#10629) that is already on this branch. ## How did you test it? - [x] built (`go build ./service/worker/batcher/... ./common/dynamicconfig/... ./common/log/...`) - [x] covered by existing tests ## Potential risks Cherry-pick applies cleanly. Risk limited to admin batch RPS control behavior, gated by dynamic config. Co-authored-by: Yichao Yang <yichao@temporal.io>
…mporalio#10630) (temporalio#10657) ## What changed? Backports temporalio#10630 to `cloud/v1.32.0-157`. Workers now retry retryable task failures in place and emit exactly one response per task instead of re-queuing onto the worker-only task channel; the heartbeat resume point tracks the oldest incomplete page; the worker count is clamped to at least 1; and the loop stops submitting empty tasks once a page is fully submitted. ## Why? Patch the 1.32.0-157 release: re-queuing retries onto the worker-only `taskCh` could deadlock the worker pool under a burst of retryable errors, leaving the admin/batch activity heartbeating with no progress. Adapted, not a clean cherry-pick: 1.32.0-157 predates temporalio#10627, so this targets the pre-temporalio#10627 batcher structure (and converts the touched `errors.New(fmt.Sprintf)` sites to `fmt.Errorf` plus `eventId`→`eventID` to satisfy the linters on the moved code). ## How did you test it? - [x] built (`go build ./service/worker/batcher/...`) - [x] covered by existing tests - [x] added new unit test(s) ## Potential risks Retries hold a worker slot while retrying, bounded by AttemptsOnRetryableError. Scope limited to admin/batch operation processing.
lilydoar
force-pushed
the
cloud/v1.32.0-157
branch
from
June 15, 2026 17:17
020f291 to
754cbf9
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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?
Potential risks
Any change is risky. Identify all risks you are aware of. If none, remove this section.