{ "schemaVersion": 3, "dataset": { "version": 3, "date": "2026-08-13", "group": { "id": "platform-infrastructure", "name": "Platform / Networking / Runtime Infrastructure" }, "repository": { "id": "temporal", "repo": "temporalio/temporal", "name": "Temporal", "keywords": [ "Temporal.io", "Temporal workflow" ] }, "context": { "repository": "temporalio/temporal", "url": "https://github.com/temporalio/temporal", "description": "Temporal service", "homepage": "https://docs.temporal.io", "language": "Go", "topics": [ "cronjob-scheduler", "distributed-cron", "distributed-systems", "durable-execution", "golang", "microservice-framework", "microservice-orchestration", "microservices-architecture", "orchestrator", "service-bus", "service-fabric", "workflow-automation", "workflow-engine", "workflow-management", "workflow-management-system", "workflows" ], "license": "MIT", "defaultBranch": "main", "stars": 22285, "forks": 1808, "openIssues": 890, "archived": false, "collectedAt": "2026-08-13T18:01:58.960116+00:00" }, "news": { "repository": "temporalio/temporal", "collectedAt": "2026-08-13T18:01:58.960116+00:00", "latestRelease": { "repository": "temporalio/temporal", "tag": "v1.31.2", "title": "v1.31.2", "url": "https://github.com/temporalio/temporal/releases/tag/v1.31.2", "publishedAt": "2026-07-08T17:10:11Z", "notes": "## What's Changed\r\n* Bump defaultCliVersion to 1.7.2 for v1.31.1 admin-tools \r\n* Cherry-pick #9917, \"Cover replication streaming endpoint with authorization\"\r\n* Update Alpine to 3.23.5\r\n\r\n\r\n### Potential Breaking Change \r\nIf using authorization with replication setup, set `system.disableStreamingAuthorizer` dynamic config to `true` to opt out from changes in this release and avoid replication traffic connection errors. Check the linked CVE for implications of opting out.\r\n\r\n### **Security**\r\n- Addresses [CVE-2026-5724](https://www.cve.org/cverecord?id=CVE-2026-5724), MEDIUM\r\n\r\n**Full Changelog**: https://github.com/temporalio/temporal/compare/v1.31.1...v1.31.2", "highlights": [ "What's Changed", "Bump defaultCliVersion to 1.7.2 for v1.31.1 admin-tools", "Cherry-pick #9917, \"Cover replication streaming endpoint with authorization\"", "Update Alpine to 3.23.5", "Potential Breaking Change", "Security" ], "prerelease": false }, "upcoming": [], "communityDiscussions": [] }, "runs": [ { "collectedAt": "2026-08-13T12:26:38.318Z", "since": "2026-08-12T12:26:38.318Z", "observedCount": 90, "changedCount": 90 }, { "collectedAt": "2026-08-13T13:48:00.446149Z", "since": "2026-08-12T13:48:00.446149Z", "observedCount": 88, "changedCount": 88 }, { "collectedAt": "2026-08-13T16:19:22.035158Z", "since": "2026-08-12T16:19:22.035158Z", "observedCount": 92, "changedCount": 29 }, { "collectedAt": "2026-08-13T17:43:20.785491Z", "since": "2026-08-12T17:43:20.785491Z", "observedCount": 87, "changedCount": 20 }, { "collectedAt": "2026-08-13T17:47:07.884300Z", "since": "2026-08-12T17:47:07.884300Z", "observedCount": 87, "changedCount": 7 }, { "collectedAt": "2026-08-13T18:01:55.420671Z", "since": "2026-08-12T18:01:55.420671Z", "observedCount": 89, "changedCount": 8 } ], "signals": [ { "id": "github:temporalio/temporal:issue:10579", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "Schedule deadlocks after Workflow ID reuse when previous scheduled action has Workflow Retry chain", "text": "## Temporal version - Temporal Server: 1.31.0 - Persistence: PostgreSQL - Visibility: Elasticsearch ## Summary A Schedule's internal scheduler Workflow can become permanently blocked in `refreshWorkflows` when: 1. A Schedule-started Workflow has a Workflow-level Retry Policy. 2. The scheduled execution exhausts retries, producing a multi-run chain ending in failure. 3. A separate manual execution reuses the Schedule-generated Workflow ID that has a multi-run chain. 4. The next scheduled action attempts to refresh the previous action. The scheduler watcher repeatedly fails with: ```text WatchWorkflow: last event did not have correct attrs ``` The Schedule stops launching actions. Pause/unpause signals do not recover it because the scheduler Workflow remains blocked waiting for an endlessly retried local activity. ## Reproduction Create a Schedule like: ```go ScheduleActionStartWorkflow{ ID: \"example\", Workflow: ExampleWorkflow, RetryPolicy: &temporal.RetryPolicy{ MaximumAttempts: 3, }, } ``` Use default Skip overlap policy. The Schedule generates a Workflow ID like: ```text example-2026-06-03T12:20:00Z ``` Steps: 1. Make the scheduled Workflow fail through all three Workflow retry attempts. 2. Before the next scheduled tick, manually start a separate Workflow execution using the exact generated ID: ```text example-2026-06-03T12:20:00Z ``` 3. Wait for the next scheduled tick. ## Expected behavior The scheduler identifies the previous scheduled chain as closed, records terminal status, and starts/skips the next action normally. ## Actual behavior The Schedule becomes permanently stuck: ```text recent action status: RUNNING actual scheduled Workflow chain status: FAILED RunningWorkflows: [] bufferSize: 1 next action time: in past ``` Internal scheduler stack: ```text refreshWorkflows processWatcherResult WatchWorkflow ``` Internal scheduler history repeatedly records: ```text WatchWorkflow: last event did not have correct attrs ``` Pause/unpause signals are accepted into history but are not processed. ## Root cause analysis Scheduled retry chain: ```text Run A — Continue-As-New Run B — Continue-As-New Run C — Failed ``` Scheduler tracks: ```text WorkflowId: example-2026-06-03T12:20:00Z FirstExecutionRunId: Run A ``` Manual execution creates a newer independent chain with the same Workflow ID: ```text Run D — separate FirstExecutionRunId ``` Watcher first queries latest execution by Workflow ID without Run ID: ```go Execution: &commonpb.WorkflowExecution{WorkflowId: ex.WorkflowId}, FirstExecutionRunId: ex.RunId, ``` Latest execution is manual Run D. Watcher detects a different chain and follows the scheduled chain using its first Run ID: ```go if pollRes.FirstExecutionRunId != req.FirstExecutionRunId { if len(req.Execution.RunId) == 0 { return nil, errFollow(req.FirstExecutionRunId) } } ``` The resulting response combines: ```text WorkflowStatus: FAILED Close event: WORKFLOW_EXECUTION_CONTINUED_AS_NEW ``` Status represents the terminal retry chain, while the close event belongs to the initial run. `responseBuilder.Build` branches on `FAILED`, expects failed-event attributes, receives a Continue-As-New event, then returns `errNoAttrs`: ```go case enumspb.WORKFLOW_EXECUTION_STATUS_FAILED: if attrs := event.GetWorkflowExecutionFailedEventAttributes(); attrs == nil { return nil, errNoAttrs } ``` The local activity retries forever, blocking the scheduler Workflow. ## Relevant source - Wrong-chain fallback: https://github.com/temporalio/temporal/blob/v1.31.0/service/worker/scheduler/activities.go#L143-L151 - Close-event interpretation: https://github.com/temporalio/temporal/blob/v1.31.0/service/worker/scheduler/activities.go#L302-L349 - Blocking refresh: https://github.com/temporalio/temporal/blob/v1.31.0/service/worker/scheduler/workflow.go#L1544-L1558 ## Suggested fix When following `FirstExecutionRunId`, ensure `PollMutableState` status and fetched close event refer to the same terminal execution. Also make `errNoAttrs` non-retryable or otherwise prevent `WatchWorkflow` from permanently blocking Schedule processing.", "url": "https://github.com/temporalio/temporal/issues/10579", "createdAt": "2026-06-06T18:19:39Z", "updatedAt": "2026-08-13T02:34:12Z", "timestamp": "2026-08-13T02:34:12Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "tianrendong", "state": "open", "assignees": [ "chaptersix" ] }, { "id": "github:temporalio/temporal:issue:10841", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "SignalWithStart hangs forever on an orphaned current-execution pointer", "text": "## Expected Behavior `SignalWithStartWorkflowExecution` for a workflow ID makes progress: it either signals the running execution or starts a new run, and returns within the client deadline. I suppose, but haven't checked, that this behavior could occur in other APIs which interacts with current executions in a similar fashion (Continue As New?, Updates?, ...) ## Actual Behavior We have observed that `SignalWithStart` API call for **one** workflow ID to fail consistently with `context deadline exceeded` error, across multiple calling services, indefinitely. Other workflows are unaffected. What we found is that that workflow is in a corrupt state in Cassandra: the current-execution pointer row (sentinel `permanentRunID`) is here, but the mutable state and history of the run it points to are both gone. Reading the rows on the owning shard shows the pointer present, zero mutable-state rows for the referenced run, and zero history nodes. The pointer's decoded `execution_state` names a run that completed with status `TIMED_OUT`. Running an `AdminService`'s `DeleteWorkflowExecution` API call on the workflow ID / run ID cleared up the dangling row and let the `SignalWithStart` API call succeed afterwards. Here is the reasoning of what could happen: `SignalWithStart` [resolves the current run from the pointer](https://github.com/temporalio/temporal/blob/v1.30.4/service/history/api/signalwithstartworkflow/api.go#L37-L45), then [loads that run's mutable state](https://github.com/temporalio/temporal/blob/v1.30.4/service/history/api/consistency_checker.go#L298). The [load returns NotFound, so the call treats it as \"no current execution\"](https://github.com/temporalio/temporal/blob/v1.30.4/service/history/api/signalwithstartworkflow/api.go#L50-L51) and takes the [brand-new path (`CreateWorkflowModeBrandNew`)](https://github.com/temporalio/temporal/blob/v1.30.4/service/history/api/signalwithstartworkflow/signal_with_start_workflow.go#L234). That insert is [conditioned on `IF NOT EXISTS` for the current row](https://github.com/temporalio/temporal/blob/v1.30.4/common/persistence/cassandra/mutable_state_store.go#L49), which still exists, so it [fails with `CurrentWorkflowConditionFailedError`](https://github.com/temporalio/temporal/blob/v1.30.4/common/persistence/cassandra/errors.go#L185-L215). The [handler retries, hits the same condition, and loops](https://github.com/temporalio/temporal/blob/v1.30.4/service/history/handler.go#L1057-L1070) until the client deadline. No path reconciles a present pointer against a missing target run, so the call never succeeds. ## Steps to Reproduce the Problem 1. Create and complete a workflow so a current-execution pointer exists for run X. 1. At the persistence layer, delete the mutable-state row and history nodes for run X, but leave the current-execution pointer row intact. 1. Call `SignalWithStartWorkflowExecution` for that workflow ID, and observe it retry internally and fail with a deadline. ## Specifications - Version: v1.30.4 - Platform: Self hosted, backed by Cassandra ## Additional Context We suspect the pointer row was resurrected at the persistence layer. Looking at the code it seems workflow deletions removes the pointer before the mutable state and history, so a partial failure would leave the pointer gone, not surviving, and to the best of my knowledge, no code seems to writes the pointer for a closed workflow. The likely mechanism is Cassandra deleted-row resurrection: the pointer's tombstone expired before every replica compacted it, and a later repair streamed the pre-delete pointer back while the mutable-state and history tombstones stuck. The specific workflow we observed behavior on is over a year old, which is ample time for that to happen.", "url": "https://github.com/temporalio/temporal/issues/10841", "createdAt": "2026-06-25T09:58:11Z", "updatedAt": "2026-08-13T02:54:24Z", "timestamp": "2026-08-13T02:54:24Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "potential-bug" ], "author": "lminaudier", "state": "open", "assignees": [ "yycptt" ] }, { "id": "github:temporalio/temporal:issue:11314", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "Replace LeveledCompactionStrategy (LCS) with Cassandra 5.x default UnifiedCompactionStrategy (UCS) in schema.cql", "text": "**Description** The Cassandra schema file [/cassandra/temporal/schema.cql](https://github.com/temporalio/temporal/blob/main/schema/cassandra/temporal/schema.cql) currently configures nearly all tables with LeveledCompactionStrategy (LCS). LCS is not a good general-purpose default — it's optimized for read-heavy workloads with low write amplification tolerance, and imposes unnecessary compaction overhead for tables that don't need it. Cassandra 5.0 introduces UnifiedCompactionStrategy (UCS) as the new default, which is designed to work well as a general-purpose strategy across a broader range of workloads. **Describe the solution you'd like** Remove the explicit WITH COMPACTION = {...} clause from each table definition in schema.cql. Dropping the clause lets each table fall back to the engine's default compaction strategy: On Cassandra 5.x, this will default to UnifiedCompactionStrategy (UCS). On earlier Cassandra versions, this will default to SizeTieredCompactionStrategy (STCS), so backward compatibility is preserved. This avoids hardcoding a compaction strategy choice in the schema and lets each Cassandra version apply its own sensible default.", "url": "https://github.com/temporalio/temporal/issues/11314", "createdAt": "2026-07-27T18:59:24Z", "updatedAt": "2026-08-13T02:50:29Z", "timestamp": "2026-08-13T02:50:29Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "enhancement" ], "author": "bschoening", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:issue:11497", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "Request Patch Release - For High & Critical Vulnerabilities in latest images - AWS Inspector Report", "text": "# AWS Inspector Vulnerability Scan Report (CRITICAL & HIGH Only) Scan performed on the latest Temporal images using Amazon ECR Enhanced Scanning with AWS Inspector. ## Test Metadata - **Test Date:** August 12, 2026 - **Tested Versions:** | Image | Version | Image Digest | |---|---|---| | `temporalio/ui:latest` | **v2.53.2** | `sha256:f3a23c7133762f9bbdd7b3408cd14ec79ea7653f6f7edb4f136696303e345c12` | | `temporalio/admin-tools:latest` | **v1.31.2** (server), **v1.7.3** (cli) | `sha256:4baf14a7488ac6fabd70aaf3c73d83163bd88f38b891afbc7aa6e8a114d4097c` | | `temporalio/server:latest` | **v1.31.2** | `sha256:931ef2bc6b5c7c9ae181ce03d7d37a44ebdaa4ac5f0dc0c7067c321961224f3a` | --- ## Image: `temporalio/ui:latest` (v2.53.2) **8 CRITICAL, 11 HIGH** | Severity | Vulnerability ID | Affected Package | |---|---|---| | **CRITICAL** | CVE-2026-39821 | golang.org/x/net | | **CRITICAL** | CVE-2026-39830 | golang.org/x/crypto | | **CRITICAL** | CVE-2026-39831 | golang.org/x/crypto | | **CRITICAL** | CVE-2026-39832 | golang.org/x/crypto | | **CRITICAL** | CVE-2026-39833 | golang.org/x/crypto | | **CRITICAL** | CVE-2026-39834 | golang.org/x/crypto | | **CRITICAL** | CVE-2026-42508 | golang.org/x/crypto | | **CRITICAL** | CVE-2026-46595 | golang.org/x/crypto | | **HIGH** | CVE-2026-27145 | go/stdlib | | **HIGH** | CVE-2026-33814 | golang.org/x/net | | **HIGH** | CVE-2026-39822 | go/stdlib | | **HIGH** | CVE-2026-39828 | golang.org/x/crypto | | **HIGH** | CVE-2026-39829 | golang.org/x/crypto | | **HIGH** | CVE-2026-39835 | golang.org/x/crypto | | **HIGH** | CVE-2026-42504 | go/stdlib | | **HIGH** | CVE-2026-46597 | golang.org/x/crypto | | **HIGH** | CVE-2026-46600 | golang.org/x/net | | **HIGH** | CVE-2026-56852 | golang.org/x/text | | **HIGH** | GHSA-hrxh-6v49-42gf | google.golang.org/grpc | --- ## Image: `temporalio/admin-tools:latest` (v1.31.2) **0 CRITICAL, 4 HIGH** | Severity | Vulnerability ID | Affected Package | |---|---|---| | **HIGH** | CVE-2026-39822 | go/stdlib and 3 more | | **HIGH** | CVE-2026-46600 | golang.org/x/net and 3 more | | **HIGH** | CVE-2026-56852 | golang.org/x/text and 3 more | | **HIGH** | GHSA-hrxh-6v49-42gf | google.golang.org/grpc and 3 more | --- ## Image: `temporalio/server:latest` (v1.31.2) **0 CRITICAL, 4 HIGH** | Severity | Vulnerability ID | Affected Package | |---|---|---| | **HIGH** | CVE-2026-39822 | go/stdlib | | **HIGH** | CVE-2026-46600 | golang.org/x/net | | **HIGH** | CVE-2026-56852 | golang.org/x/text | | **HIGH** | GHSA-hrxh-6v49-42gf | google.golang.org/grpc | --- ## Summary | Image | CRITICAL | HIGH | Total | |---|---|---|---| | `temporalio/ui:latest` (v2.53.2) | 8 | 11 | 19 | | `temporalio/admin-tools:latest` (v1.31.2) | 0 | 4 | 4 | | `temporalio/server:latest` (v1.31.2) | 0 | 4 | 4 | | **Grand Total** | **8** | **19** | **27** | > [!NOTE] > There could be missing changes in CVEs as and when detected.", "url": "https://github.com/temporalio/temporal/issues/11497", "timestamp": "2026-08-12T13:16:16Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "potential-bug" ], "author": "antigravity-sketch", "assignees": [], "change": "new" }, { "id": "github:temporalio/temporal:issue:11534", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "Fairsim partial counter configuration resets unspecified defaults", "text": "## Expected Behavior The partial counter configuration documented in `tools/fairsim/README.md` should override only the supplied values. For example: ```bash ./fairsim \\ -counter-params=<(echo '{\"CMS\":{\"W\":100}}') \\ -- -tasks=1000 -keys=500 ``` should set the CMS width to `100` while retaining all other values from `counter.DefaultCounterParams`. ## Actual Behavior `fairsim` unmarshals the JSON into a zero-valued `counter.CounterParams`. Omitted values such as `MapLimit`, CMS depth, growth settings, and reseeding interval therefore become zero. The loaded configuration includes: ```text MapLimit: 0 CMS.W: 100 CMS.D: 0 CMS.Grow: zero values CMS.Reseed.Interval: 0 ``` With `MapLimit` set to zero, processing the first task can panic in `mapCounter.updateHeap`. It also means that changing one CMS setting unintentionally changes the rest of the simulated counter configuration. ## Steps to Reproduce the Problem 1. Build `fairsim` from an unmodified checkout: ```bash make fairsim ``` 2. Run the partial configuration example: ```bash ./fairsim \\ -counter-params=<(echo '{\"CMS\":{\"W\":100}}') \\ -- -tasks=1000 -keys=500 ``` 3. Observe that unspecified counter parameters are zero instead of retaining their defaults, potentially followed by an index-out-of-range panic. ## Proposed Resolution Initialize the configuration with `counter.DefaultCounterParams` before unmarshalling the supplied JSON. This makes partial configuration files behave as documented while continuing to support explicit zero values. A regression test can load `{\"CMS\":{\"W\":10}}` and verify that only `CMS.W` changes while all other fields remain equal to `counter.DefaultCounterParams`. ## Specifications - Version: `main` at `632d694e7` - Platform: Linux amd64", "url": "https://github.com/temporalio/temporal/issues/11534", "createdAt": "2026-08-13T10:56:52Z", "updatedAt": "2026-08-13T11:35:38Z", "timestamp": "2026-08-13T11:35:38Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "Aminkbi", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:issue:11539", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "DeleteWorkerDeploymentVersion fails permanently when a version summary outlives its version workflow", "text": "### What are you really trying to do? Keep the number of Worker Deployment Versions per deployment under `matching.maxVersionsInDeployment` by periodically deleting drained versions, so that new versions can always register. ### Describe the bug A Worker Deployment can end up listing a version in `DescribeWorkerDeployment`'s `versionSummaries` **after that version's own entity/workflow no longer exists**. Once in that state the entry is **permanently undeletable**: `DeleteWorkerDeploymentVersion` runs against a version workflow that isn't there and fails on every attempt, forever. The entry keeps counting toward `maxVersionsInDeployment`, and any automated cleanup that walks `versionSummaries` and deletes drained versions fails on it indefinitely. Observed on **server 1.30.3** (CLI 1.6.x), Postgres persistence, one namespace with 30d retention. The three views disagree with each other for the same build ID (names below are anonymized; `worker-a` is a deployment with 1 current + 21 drained versions, `1.42.0-a1b2` is the oldest drained one, created ~24 days earlier): ``` $ temporal worker deployment describe --name default/worker-a -o json -> versionSummaries contains build ID 1.42.0-a1b2, drainageStatus \"drained\" $ temporal worker deployment describe-version \\ --deployment-name default/worker-a --build-id 1.42.0-a1b2 ERROR error describing worker deployment version: build ID '1.42.0-a1b2' not found in Worker Deployment 'default/worker-a' $ temporal workflow describe \\ --workflow-id temporal-sys-worker-deployment-version:default/worker-a/1.42.0-a1b2 ERROR failed describing workflow: workflow not found for ID: ... ``` So the deployment workflow's version list and the version entities have diverged. Deleting it fails deterministically: ``` $ temporal worker deployment delete-version \\ --deployment-name default/worker-a --build-id 1.42.0-a1b2 --identity ERROR error deleting worker deployment version: something went wrong, please retry (36634b00) ``` The retry hint is misleading — it is not transient. Every invocation over ~2 days failed identically. ### Root cause as far as we could trace it The generic frontend error hides the real failure. The frontend logs only the wrapper: ``` {\"level\":\"error\",\"msg\":\"deployment client unexpected error\",\"error\":\"activity error\", \"operation\":\"DeleteWorkerDeploymentVersion\",\"deployment\":\"default/worker-a\", \"args\":[\"default\",\"1.42.0-a1b2\"], \"logging-call-at\":\"service/worker/workerdeployment/client.go:1266\"} ``` The actual cause appears only in the **system worker** logs: ``` {\"level\":\"error\",\"msg\":\"Activity error.\", \"Namespace\":\"default\",\"TaskQueue\":\"temporal-sys-per-ns-tq\", \"WorkflowID\":\"temporal-sys-worker-deployment:default/worker-a\", \"ActivityType\":\"DeleteWorkerDeploymentVersion\",\"Attempt\":1, \"Error\":\"workflow execution already completed\"} ``` i.e. the deployment workflow's `DeleteWorkerDeploymentVersion` activity targets the version workflow, finds it already completed/absent, and surfaces that as a non-actionable internal error instead of treating the desired end state (version gone) as satisfied. ### Suspected trigger Not conclusively established, so treat this as a hypothesis: the version workflow closed when the version drained and was then removed by **namespace retention** (30d here), while the deployment workflow — which continues-as-new and carries its version list forward — kept the summary entry. The affected version was the oldest in the deployment, consistent with it being the first to cross the retention boundary. If that is the mechanism, any long-lived deployment should accumulate these as versions age past retention. ### Minimal repro We do not have a clean synthetic repro, which is why the mechanism above is a hypothesis. It appeared naturally on a deployment with steady rollout churn. If retention is the trigger, the shape would be: register a version, make it current, supersede it so it drains, then let the version workflow age past the namespace retention, and attempt `delete-version` on it. ### Expected behaviour Any one of these would resolve it: 1. **`DeleteWorkerDeploymentVersion` is idempotent** — if the version workflow is already absent, remove the summary entry and return success rather than an internal error. This seems like the natural fix: the caller's intent is already satisfied. 2. **The deployment workflow prunes summaries** whose version entity no longer exists (e.g. on continue-as-new, or when a delete discovers the entity is missing). 3. Failing either, a **supported way to remove such an entry**. The only lever we can see is terminating `temporal-sys-worker-deployment:default/` so the list is rebuilt, which is not viable in production because that workflow holds live routing config (current/ramping version). Separately, and independent of the fix: **`something went wrong, please retry ()` for a permanent, non-retryable condition is hard to diagnose.** Propagating the activity's cause (or at least a distinct error type) to the caller would have saved most of this investigation. ### Impact Low severity but permanent and self-accumulating: - The stale entry consumes one slot against `maxVersionsInDeployment` (200 in our config) and can never be reclaimed. - Automated below-cap cleanup fails on it on every run. Ours ran every 6h and exited non-zero each time until we special-cased it: on a failed delete we now probe `describe-version` and, only if it reports the version as absent, count it as already-gone instead of a failure. That works, but it is a workaround for a state the server arguably shouldn't expose. ### Related Cross-referencing #10737, which covers version GC not reclaiming eligible drained versions at the cap. This looks like a distinct, second-order problem in the same area: there the versions *aren't* reclaimed, here a version *cannot* be reclaimed because the summary outlived the entity. ### Environment - Temporal Server: 1.30.3 (Helm, Postgres persistence, ES/advanced visibility not in use) - Temporal CLI: 1.6.x - Worker Deployment Versioning with an external controller managing rollouts; workflows are pinned by default - Relevant config: `matching.maxVersionsInDeployment: 200`; namespace retention 30d; `worker.buildIdScavengerEnabled: true`", "url": "https://github.com/temporalio/temporal/issues/11539", "createdAt": "2026-08-13T12:11:00Z", "updatedAt": "2026-08-13T12:11:00Z", "timestamp": "2026-08-13T12:11:00Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "noamyehudai", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:issue:11547", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "A brief `Unavailable` blip resets History queue backoff, causing a sustained retry storm", "text": "### Summary When a History cluster is running at its system persistence-QPS limit, the fleet stays stable only because `ResourceExhausted` errors put queue readers/task executables onto their long reschedule backoff, which spreads persistence load out over time. If persistence briefly returns a *different* transient error (`Unavailable`, or context deadline exceeded) - e.g. during a database failover/switchover - readers/executables fall back to their fast retry path, the fleet's long-backoff state is effectively reset, and on recovery every shard re-fires in a synchronized burst. The aggregate read QPS then exceeds the system persistence limiter, ack-level advancement is starved, and the queues settle into a saturated equilibrium instead of draining. ### Environment - Temporal Server version: **v1.30.2** (behavior also present, byte-identical in the relevant code, on v1.31.1 and `main` - see code pointers) - Persistence: Aurora PostgreSQL - History service running at/near its configured **system** persistence-QPS limit ### Current behavior 1. Under chronic system-QPS pressure, a fraction of persistence ops trip `ResourceExhausted`. Readers/executables detect this specific class via `IsResourceExhausted(err)` and reschedule on the long `ResourceExhausted` backoff curve (`CreateTaskResourceExhaustedReschedulePolicy`: initial ~3s, coefficient 1.5, max ~5m), which naturally de-synchronizes the fleet. `RangeCompleteHistoryTasks` slips through often enough to keep ack levels advancing. No customer impact, but zero headroom. 2. A brief persistence interruption (observed ~60s during a DB switchover) returns `Unavailable` / context-deadline for calls - the incident logs show this window as `Unavailable`/deadline, not `ResourceExhausted`. 3. The long backoff is engaged **only** when the error is `ResourceExhausted`: - Readers: on `ResourceExhausted` they wait a fixed throttle delay; for any other transient error they use the fast exponential retrier (~50ms initial → ~1s max), which is then reset once a call succeeds. - Executables: they increment a per-task `resourceExhaustedCount` and take the long reschedule **only** while that error is `ResourceExhausted`; any other error path resets `resourceExhaustedCount = 0` and falls back to the default reschedule policy (~1s initial, 1.1 coefficient, ~3m max). For the duration of the blip, every reader/executable on every shard retries on its fast/default path and the accumulated long-backoff state is discarded fleet-wide. 4. On recovery, each shard's first successful read returns a full batch with `MoreTasks=true`, which triggers an immediate re-notification (no throttle between that batch and the next read). Thousands of shards across multiple scheduled queue categories become eligible at once. Each individual reader is still gated by its own rate limiter, so this is not a single reader spinning with zero gap - it is an **aggregate, fleet-wide** synchronized burst whose combined read QPS exceeds the system persistence cap. 5. `RangeCompleteHistoryTasks` (advances ack levels by deleting completed task ranges) goes through the **same** persistence rate limiter as the reads: `GetHistoryTasks`, `CompleteHistoryTask`, and `RangeCompleteHistoryTasks` all funnel through the same `allow()` gate (system + namespace + shard limiters). Under saturation it is throttled/failed alongside the reads, so ack levels don't advance, readers re-read the same ranges every cycle, and the limiter stays saturated. Archival tasks (which read history from persistence before writing the blob) fail the same way and reschedule, compounding read load. 6. Result: a stable \"saturated\" equilibrium. Individual task executions can succeed, but queues do not logically drain. Recovery only happens by scaling persistence and/or raising the QPS limit; the backlog then drains slowly. ### Expected behavior A short-lived `Unavailable`/deadline condition on a cluster that is otherwise persistence-rate-limited should not collapse the fleet's backoff and cause a persistent retry storm. Specifically: - Transient non-`ResourceExhausted` persistence errors should not discard readers'/executables' long-backoff state in a way that synchronizes the whole fleet on recovery. - Ack-level advancement (`RangeCompleteHistoryTasks`) should not have to compete on equal footing with the same reader load it is trying to relieve - otherwise there is no escape path from saturation. ### Impact Extended (multi-hour) stall of workflow progress across all shards on the affected cluster: workflow starts, signals, workflow-task completions, timer fires, and archival all intermittently fail or make no progress, even though the database itself is healthy after the blip. Frontend availability metrics understate the impact because affected shards make zero forward progress regardless of client retries. ### Suggested directions (for discussion) 1. Apply the congestion-style long/jittered backoff to a broader set of transient persistence errors - at minimum `Unavailable` and context-deadline - not just `ResourceExhausted`, so a brief outage doesn't reset the fleet to the fast curve. 2. Add jitter / de-synchronization to reader re-fire after recovery so shards don't dispatch in lockstep when persistence returns. 3. Give ack-level advancement (`RangeCompleteHistoryTasks`) priority or a separate budget from read traffic through the persistence limiter, so the queue always has an escape path from saturation. 4. Gate immediate `MoreTasks=true` re-fires (e.g. small jittered delay) so a synchronized fleet of recovery batches can't collectively produce a read burst that exceeds the persistence cap. ### Relevant code pointers - `common/util.go`: `CreateTaskResourceExhaustedReschedulePolicy` (the long backoff, applied specifically for resource-exhausted); `IsResourceExhausted` (the actual decision point that selects the long curve); `IsPersistenceTransientError` (treats both `Unavailable` and `ResourceExhausted` as transient/retryable, but only the latter gets the long reschedule). - `service/history/queues/reader.go`: fixed throttle delay on `ResourceExhausted` vs. the fast exponential retrier for other errors; `MoreTasks()` immediate re-notification. - `service/history/queues/executable.go`: `resourceExhaustedCount` (incremented only on `ResourceExhausted`, reset to `0` on any other outcome) selecting the long reschedule. - `common/persistence/persistence_rate_limited_clients.go`: `GetHistoryTasks`, `CompleteHistoryTask`, and `RangeCompleteHistoryTasks` all pass through the same `allow()` gate (shared system/namespace/shard rate limiters) - so ack-advancement competes with reads for the same budget. *(Code paths above verified identical at tags `v1.30.2`, `v1.31.1`, and `main`.)*", "url": "https://github.com/temporalio/temporal/issues/11547", "createdAt": "2026-08-13T16:15:43Z", "updatedAt": "2026-08-13T16:19:14Z", "timestamp": "2026-08-13T16:19:14Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "ggbata", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:issue:2341", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "config: strict mode for configuration parsing", "text": "**Is your feature request related to a problem? Please describe.** My team is working on a new deployment of Temporal and we recently spent an entire day debugging an issue related to a missing key in configuration due to lack of error messaging and validation by the bootstrap code. Example: ``` metrics: hostPort: \"127.0.0.1:8125\" prefix: \"temporal\" ``` needed to be ``` metrics: statsd: hostPort: \"127.0.0.1:8125\" prefix: \"temporal\" ``` The server started up fine, the logic to configure the [bootstrap code looked for any of the custom configured reporters](https://github.com/temporalio/temporal/blob/e153684480968b9b271574b589abaedd5525a255/common/metrics/config.go#L260-L271), didn't find any, and everything booted as normal, only we were not getting any stats. **Describe the solution you'd like** I would like the option for strict config validation. If a key is unrecognized, the server should fail to start so it can be corrected. I'm happy to put together a PR for option 1 below if someone can give their thoughts and approval on the approach. **Describe alternatives you've considered** - **Option 1** Change YAML unmarshaling to reject unknown fields (see [yaml.Decoder.KnownFields](https://pkg.go.dev/gopkg.in/yaml.v3#Decoder.KnownFields)), and ideally expand the use of the `gopkg.in/validator.v2` throughout the config structs. Could we move to this as a default? If not add a flag which the server supports to unmarshal the config in strict mode. - **Option 2** Move to protobuf for configuration specifications. This would have the benefit of centralizing config specifications in a single place and definition language rather than scattering structs throughout the code base. I previously made this suggestion in a [`#development Slack thread](https://temporalio.slack.com/archives/CTQU95E84/p1639591413096200): > Has the team considered moving to protobuf for the config schema? discovery and validation are subpar with how it's all done with structs currently. Example from our project [lyft/clutch](github.com/lyft/clutch) which uses proto for defining config and uses [envoyproxy/protoc-gen-validate](https://github.com/envoyproxy/protoc-gen-validate) for validation: > - Config definition: [api/config/gateway/v1/gateway.proto](https://github.com/lyft/clutch/blob/43aa67e73d776f3d232ea5d1188f01e194c50b63/api/config/gateway/v1/gateway.proto). > - Example YAML conforming to definition: [clutch-config.yaml](https://github.com/lyft/clutch/blob/43aa67e73d776f3d232ea5d1188f01e194c50b63/backend/clutch-config.yaml) > - Example output from a bad config: `{\"level\":\"fatal\",\"ts\":1641326218.3299987,\"caller\":\"gateway/config.go:71\",\"msg\":\"configuration proto validation failed\",\"file\":\"clutch-config.yaml\",\"error\":\"invalid Config.Gateway: embedded message failed validation | caused by: invalid GatewayOptions.Listener: value is required\"}`", "url": "https://github.com/temporalio/temporal/issues/2341", "createdAt": "2022-01-04T20:12:59Z", "updatedAt": "2026-08-12T16:09:47Z", "timestamp": "2026-08-12T16:09:47Z", "metrics": { "reactions": 1, "comments": 5 }, "labels": [ "enhancement", "up-for-grabs" ], "author": "danielhochman", "state": "open", "assignees": [ "yiminc" ], "change": "updated" }, { "id": "github:temporalio/temporal:issue:6173", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "Schedule \"StartAt\" not used when calculating intervals?", "text": "Today is _June 19th, 2024_. If you create a schedule and specify \"every 365 days\" the result will be that the first run is on `2024-12-18 00:00:00`. **That's in 6 months**. I've tried passing `StartAt: 2025-06-19` but I get `2025-12-18 00:00:00` as a result. I understand this may be known and as-designed behavior but it struck me as unexpected to ask for a 365 day interval, yet the first run is within the next 6 months. I also don't see any way to achieve my desired result. Am I missing anything? _EDIT_: I also can't use the _offset_ to control this behavior because I don't know what the final calculation will be until the schedule is created. ## Expected Behavior In the example above, I'd prefer to have the schedule's first run be at my specified \"StartAt\". So, if I say: \"Start this workflow every 365 days with start at 2025-02-03 04:05:06\", then the upcoming runs would look like: * 2025-02-03 04:05:06 * 2026-02-03 04:05:06 * 2027-02-03 04:05:06 * etc. ## Actual Behavior When I pick 365 days as the interval, I seem to be getting a date 6 months in the future. ## Steps to Reproduce the Problem 1. Go to temporal UI and add a schedule. 1. Choose 365 days and save. 1. Check the schedule's upcoming runs. ## Specifications - Version: - Platform:", "url": "https://github.com/temporalio/temporal/issues/6173", "createdAt": "2024-06-19T17:59:22Z", "updatedAt": "2026-08-13T02:35:05Z", "timestamp": "2026-08-13T02:35:05Z", "metrics": { "reactions": 1, "comments": 0 }, "labels": [ "potential-bug" ], "author": "nunofgs", "state": "open", "assignees": [ "chaptersix" ] }, { "id": "github:temporalio/temporal:issue:8087", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "[Scheduled Actions] Skipped Action Metric", "text": "**Is your feature request related to a problem? Please describe.** We'd like to have a metric for whenever schedules skip a scheduled run for any reason (either by overlap policy, missing the catchup window, or from a buffer overrun). **Describe the solution you'd like** - A new metric is introduced to keep track of skipped scheduled runs. **Describe alternatives you've considered** - Changes to record skipped schedules in a schedule's visibility record and/or the memo would still necessitate polling to record and alarm on their values. **Additional context** - Customers would like to alarm on when a scheduled run was missed or skipped.", "url": "https://github.com/temporalio/temporal/issues/8087", "createdAt": "2025-07-22T21:24:56Z", "updatedAt": "2026-08-13T02:29:28Z", "timestamp": "2026-08-13T02:29:28Z", "metrics": { "reactions": 1, "comments": 1 }, "labels": [ "enhancement", "feature-request", "schedules" ], "author": "lina-temporal", "state": "open", "assignees": [ "chaptersix" ] }, { "id": "github:temporalio/temporal:issue:8490", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "Scheduled Actions doesn't clear ContinuedFailure on null success payloads", "text": "## Expected Behavior - When a scheduled action succeeds, subsequent scheduled actions should not receive a `ContinuedFailure` failure payload. ## Actual Behavior - If a scheduled action fails, setting `ContinuedFailure`'s payload, and then a subsequent scheduled action succeeds without returning a payload (a `null` payload), `ContinuedFailure` will continue to propagate to scheduled actions.", "url": "https://github.com/temporalio/temporal/issues/8490", "createdAt": "2025-10-15T21:10:47Z", "updatedAt": "2026-08-13T02:30:09Z", "timestamp": "2026-08-13T02:30:09Z", "metrics": { "reactions": 2, "comments": 2 }, "labels": [ "bug", "schedules" ], "author": "lina-temporal", "state": "open", "assignees": [ "chaptersix" ] }, { "id": "github:temporalio/temporal:issue:9522", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "Unable to create visibility database schema for MySQL", "text": "I’m trying to self-host Temporal v1.29 using Helm. For both default and visibility databases I use MySQL 8.0.45. I get the following error in the manage-schema-visibility-store job: ERROR Unable to update SQL schema. {“error”: “error executing statement: Error 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '“$.TemporalChangeVersion”),\\n ADD COLUMN BinaryChecksums JSON ’ at line 3”, “logging-call-at”: “/home/runner/work/docker-builds/docker-builds/temporal/tools/sql/handler.go:53”} Maybe a smart quote issue? In the source code they seem to be normal quotes though.", "url": "https://github.com/temporalio/temporal/issues/9522", "createdAt": "2026-03-15T13:14:20Z", "updatedAt": "2026-08-13T08:45:00Z", "timestamp": "2026-08-13T08:45:00Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "potential-bug" ], "author": "ByulentMehmed", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:10129", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Reduce test runner resources", "text": "## What changed? Only use 4-core ARM runners instead of 8-core; and increase shard size for test sharding. ## Why? 8-core runners have - at least during peak hours - very long provisioning time (several minutes). By using 4-core we reduce that time, but risk OOM kills as they have less memory. To counter that, we increase the number of test shards so that fewer tests are run per shard. ## How did you test it? TBD", "url": "https://github.com/temporalio/temporal/pull/10129", "createdAt": "2026-04-30T01:04:58Z", "updatedAt": "2026-08-12T18:32:09Z", "timestamp": "2026-08-12T18:32:09Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "test-all-dbs" ], "author": "stephanos", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:10200", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Validator generator [WiP]", "text": "## What changed? Opt-in validator that exhaustively validate all protobuf fields in 1 place. ## Why? Adds semantic validation for protobufs as a thin layer before the proto request reaches actual business logic. ## How did you test it? - [ ] built - [ ] run locally and tested manually - [ ] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s)", "url": "https://github.com/temporalio/temporal/pull/10200", "createdAt": "2026-05-08T01:12:05Z", "updatedAt": "2026-08-13T15:39:41Z", "timestamp": "2026-08-13T15:39:41Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:10377", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Await 2.0", "text": "## 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? - [ ] built - [ ] run locally and tested manually - [ ] covered by existing tests - [ ] added new unit test(s) - [ ] added new functional test(s) ## Potential risks _Any change is risky. Identify all risks you are aware of. If none, remove this section._", "url": "https://github.com/temporalio/temporal/pull/10377", "createdAt": "2026-05-24T20:05:59Z", "updatedAt": "2026-08-12T22:50:31Z", "timestamp": "2026-08-12T22:50:31Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:10417", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Adaptive test timeouts via Await", "text": "## What changed? Adds `testcontext.EnsureRemaining` and has `await` use it so long await calls can request additional test-scoped context time while still respecting the test context cap. ## Why? Await calls can need more time than the default test context has left (esp after the environment setup). Extending the test timeout in this way allows for (1) stuck tests to fail earlier than the default test timeout and (2) legitimately longer running tests to pass without manually tweaking the test timeout.", "url": "https://github.com/temporalio/temporal/pull/10417", "createdAt": "2026-05-28T22:24:57Z", "updatedAt": "2026-08-12T22:54:05Z", "timestamp": "2026-08-12T22:54:05Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:10643", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Downscale test runner size, increase shards", "text": "## What changed? Only use 4-core ARM runners instead of 8-core; and increase shard size for test sharding. ## Why? 8-core runners have - at least during peak hours - very long provisioning time (several minutes). By using 4-core we reduce that time, but risk OOM kills as they have less memory. To counter that, we increase the number of test shards so that fewer tests are run per shard.", "url": "https://github.com/temporalio/temporal/pull/10643", "createdAt": "2026-06-10T17:58:11Z", "updatedAt": "2026-08-13T14:57:11Z", "timestamp": "2026-08-13T14:57:11Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "test-all-dbs" ], "author": "stephanos", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:10781", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Richer await timeout diagnostics", "text": "## What changed? Stacks on #10417. Adds clearer timeout diagnostics for await failures and test context cleanup after the core context-extension behavior is in place. The report now includes aligned detail rows, attempt duration summaries, attempt timeout counts, deadline-limit causes, and context extension summaries when available. The await reporting tests now exercise the public behavior directly instead of unit-testing the report helper.", "url": "https://github.com/temporalio/temporal/pull/10781", "createdAt": "2026-06-19T21:44:32Z", "updatedAt": "2026-08-12T22:50:31Z", "timestamp": "2026-08-12T22:50:31Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:10992", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "fix(persistence): skip unnecessary joins in MySQL visibility count queries", "text": "## Summary Fixes #10991 — `CountWorkflowExecutions` with `GROUP BY ExecutionStatus` was 8-16x slower than necessary on MySQL because `mysqlQueryConverter.buildCountStmt` unconditionally `LEFT JOIN`s `custom_search_attributes` and `chasm_search_attributes`, even when the query never references a column from either table. ### Root cause `GROUP BY` is only ever allowed on `ExecutionStatus` (enforced by `query.IsGroupByFieldAllowed`, checked in `convertSelectStmt`), which lives directly on `executions_visibility` — it never needs the joined tables. The joins are only actually needed when the `WHERE` clause filters on a genuine custom or CHASM search attribute column (the ones physically stored in `custom_search_attributes`/`chasm_search_attributes` per the schema, e.g. `Keyword01`, `TemporalInt01`). For the reported case (`GROUP BY ExecutionStatus`, no filter), neither table contributes anything to the result, so the joins are pure overhead — MySQL still has to do a nested-loop join against every row. Note: I checked and, contrary to the issue's claim, PostgreSQL's and SQLite's `buildCountStmt` (`query_converter_legacy_postgresql.go`, `query_converter_legacy_sqlite.go`) never had this join at all — only the MySQL variant does. So this fix is scoped to MySQL; the other two dialects just accept and ignore the new parameter to keep the shared interface consistent. ### Fix - Added `seenCustomSearchAttribute` tracking to `QueryConverterLegacy` (mirroring the existing `seenNamespaceDivision` pattern), set in `convertColName` — the single choke point where every column reference in the query is resolved — using `sadefs.IsPreallocatedCSAFieldName`/`sadefs.IsChasmSearchAttribute` to check whether the resolved field name is one of the physically-joined-table columns (not `sadefs.IsSystem`, which would incorrectly flag predefined-but-still-`executions_visibility`-resident attributes like `TemporalNamespaceDivision` as needing a join). - Threaded this through `queryParamsLegacy` → `BuildCountStmt` → the `buildCountStmt` interface method (now takes a `usesCustomSearchAttribute bool`) → `mysqlQueryConverter.buildCountStmt`, which now only emits the two `LEFT JOIN`s when that's true. ### Test plan - Added `TestBuildCountStmtSkipsJoinsWithoutCustomSearchAttribute` / `TestBuildCountStmtJoinsWithCustomSearchAttribute` in `query_converter_legacy_mysql_test.go`, asserting the generated SQL string does/doesn't contain the join clauses. - Verified the \"skips joins\" test fails (by temporarily hardcoding the join condition to always-true) and passes with the fix — confirms it actually catches the regression. - Updated existing `TestConvertWhereString`/`TestConvertWhereString_WithChasmMapper` table-driven tests in `query_converter_legacy_test.go` (shared across all 3 dialects) with the new `usesCustomSearchAttribute` field on `queryParamsLegacy`, since several existing cases (`AliasForInt01 = 1`, CHASM `ChasmStatus`) now correctly assert `true`. - `go test ./common/persistence/visibility/store/sql/...` — all pass (unit-testable, no live DB/cluster needed, as these are pure SQL-string-generation functions). - `go build ./...` — full repo builds clean. - `golangci-lint run --config=.github/.golangci.yml ./common/persistence/visibility/store/sql/...` — no new findings introduced by this change (one unrelated pre-existing `staticcheck` naming finding in `query_converter_legacy_postgresql.go` predates this diff). 🤖 Generated with [Claude Code](https://claude.com/claude-code). I've reviewed and tested every change in this PR. Note: per CONTRIBUTING.md this repo requires the Temporal CLA before merge — I understand the bot will prompt for that.", "url": "https://github.com/temporalio/temporal/pull/10992", "timestamp": "2026-08-12T13:00:42Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "Socialpranker", "assignees": [], "change": "new" }, { "id": "github:temporalio/temporal:pull_request:11033", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Return test runner orchestration outcomes", "text": "Makes test execution return an exit code and error instead of terminating inside the orchestration loop. Final artifact failures, retry-validation failures, execution errors, timeouts, and normal pass/fail outcomes are tested directly while Main remains the process-exit seam. Stack: depends on #11518 and completes the canonical Go test JSON reporting pipeline.", "url": "https://github.com/temporalio/temporal/pull/11033", "createdAt": "2026-07-13T19:38:51Z", "updatedAt": "2026-08-13T17:47:26Z", "timestamp": "2026-08-13T17:47:26Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "test-all-dbs", "request-claude-review" ], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:temporalio/temporal:pull_request:11169", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "[CHASM] Support WithRequestID on UpdateComponent", "text": "## What changed? - `WithRequestID` now applies to `UpdateComponent`, enabling execution-level idempotency guarding via request ID. - When a request ID is passed as part of an `UpdateComponent` call (via API handler), it is persisted upon successful updateFn call. If it is already present, instead, `UpdateComponent` fails with a `FailedPrecondition`. - When a request ID is not passed in, a generated ID is still created for error tracing purposes, but it is not written to mutable state. - On transaction close, mutable state will sweep the oldest RequestIDs (with an `attach_time`) upon hitting the configured limit. - This will sweep both entries below a configurable max age, as well as past a certain hard length limit. ## Why? - Scheduler's `UpdateSchedule` and `PatchSchedule` are implemented as handlers that persist a signal in V1. V1 signals provide idempotency via their request IDs. Scheduler V2 doesn't make use of signals, so instead, it must record request IDs explicitly. - We reuse the existing map within mutable state. - We *must* fail with an explicit error (`FailedPrecondition`) instead of simply returning a zero value (as Signals would on repeated successful requests). This is because `UpdateComponent` can apply to API models that include response values (which we don't record, therefore, we can't return on subsequent calls). ## How did you test it? - [ ] built - [ ] run locally and tested manually - [ ] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s)", "url": "https://github.com/temporalio/temporal/pull/11169", "createdAt": "2026-07-21T00:51:10Z", "updatedAt": "2026-08-13T17:51:12Z", "timestamp": "2026-08-13T17:51:12Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "reliability-2026" ], "author": "lina-temporal", "state": "open", "assignees": [ "fretz12" ], "change": "updated" }, { "id": "github:temporalio/temporal:pull_request:11204", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Stabilize mixed-brain server rolls", "text": "## Summary - roll four mixed-version server instances while OMES workloads run - retain each instance's port allocation across replacements and verify membership convergence - route through a mutable frontend proxy and add proxy lifecycle coverage - temporarily resolve OMES from the exact commit in temporalio/omes#426; replace this with the upstream pseudo-version after it merges ## Root cause Replacement dev servers were allocated new ports, leaving clients able to dial departed frontend addresses. ## Validation - go test -tags test_dep ./devserver (OMES) - go test -tags test_dep -run TestFrontendProxy . (mixedbrain) - make lint-code - PERSISTENCE_DRIVER=postgres12 MIXED_BRAIN_TEST_DURATION=2m make mixed-brain-test", "url": "https://github.com/temporalio/temporal/pull/11204", "createdAt": "2026-07-22T02:30:06Z", "updatedAt": "2026-08-13T02:19:58Z", "timestamp": "2026-08-13T02:19:58Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "chaptersix", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11211", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add data race summary to CI report", "text": "## What changed? Add data race summary to CI report ## Why? Notify when CI detects data race issues in main. ## How did you test it? - [X] built - [X] run locally and tested manually - [X] covered by existing tests - [X] added new unit test(s) - [ ] added new functional test(s)", "url": "https://github.com/temporalio/temporal/pull/11211", "createdAt": "2026-07-22T15:56:04Z", "updatedAt": "2026-08-12T18:06:31Z", "timestamp": "2026-08-12T18:06:31Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "awln-temporal", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11232", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "VLN-1574: remediate checkout-below-v7", "text": "> 🏕️ This pull request was created by [camper](https://github.com/temporalio/camper), an automated security campaign tool. ## Finding
Rulecheckout-below-v7
SeverityHIGH
Repositorytemporalio/temporal
TicketVLN-1574
## Summary - `.github/workflows/build-and-publish.yml`: Updated all `actions/checkout` uses to the required v7.0.0 commit pin. - `.github/workflows/check-release-dependencies.yml`: Updated `actions/checkout` to the required v7.0.0 commit pin. - `.github/workflows/ci-success-report.yml`: Updated `actions/checkout` to the required v7.0.0 commit pin. - `.github/workflows/docker-build-manual.yml`: Updated all `actions/checkout` uses to the required v7.0.0 commit pin. - `.github/workflows/features-integration.yml`: Updated `actions/checkout` to the required v7.0.0 commit pin. - `.github/workflows/flaky-tests-report.yml`: Updated `actions/checkout` to the required v7.0.0 commit pin. - `.github/workflows/govulncheck.yml`: Updated `actions/checkout` to the required v7.0.0 commit pin. - `.github/workflows/linters.yml`: Updated all `actions/checkout` uses to the required v7.0.0 commit pin. - `.github/workflows/optimize-test-sharding.yml`: Updated `actions/checkout` to the required v7.0.0 commit pin. - `.github/workflows/release.yml`: Updated `actions/checkout` to the required v7.0.0 commit pin. - `.github/workflows/run-single-test.yml`: Updated all `actions/checkout` uses to the required v7.0.0 commit pin. - `.github/workflows/run-tests.yml`: Updated all `actions/checkout` uses to the required v7.0.0 commit pin. ## Instructions - **Approve** to merge this fix - **Request changes** to trigger a new remediation attempt - `/camper rebase` — rebase onto the base branch - `/camper close` — close this PR without merging - `/camper retry` — regenerate the fix from scratch against the current base", "url": "https://github.com/temporalio/temporal/pull/11232", "createdAt": "2026-07-23T15:57:20Z", "updatedAt": "2026-08-13T17:58:35Z", "timestamp": "2026-08-13T17:58:35Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [], "author": "picatz", "state": "open", "assignees": [], "change": "new" }, { "id": "github:temporalio/temporal:pull_request:11302", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Extract replication reader-state handling into replicationReaderGroup", "text": "> **Part 2 of a 5-PR series** building to replication stream namespace isolation (a restructuring of #10147): read buffer → reader group → lane protocol → isolation manager → sender isolation. > #11263 (read buffer) has merged, so this PR's diff is now standalone against `main`. · **Next in series: #11303** (lane wire protocol + receiver routing). ## What changed? Refactors the stream sender's per-priority `QueueReaderState` arithmetic — catch-up begin watermark lookup, reader-state construction from `SyncReplicationState` acks, and failover watermark selection — into a `replicationReaderGroup` type behind a new `EnableReplicationReaderGroup` dynamic config flag (default off). Scope-index mapping is centralized in `priorityScopeIndex`, which tolerates both the single-stack (1 scope) and tiered (3 scope) persisted formats. With the flag off, behavior is byte-for-byte the pre-refactor logic — including the strict \"exactly 3 scopes\" check (states with more scopes fall back to the overall watermark). Only the flag-on path tolerates >3 scopes, which later PRs in this series use for per-lane cursors. The flag routes both the recv side (reader-state persistence) and the send side (catch-up begin lookup); changing it restarts replication streams. The dynamic config is read once in the constructor so all derived state sees one consistent snapshot. ## Why? Groundwork for replication stream namespace isolation (later PRs in this series), which extends the persisted reader state with additional per-lane scopes. Pulling the existing scope arithmetic into one place first makes the later change a pure extension instead of a rewrite, and gives the sender a single point that understands the persisted scope layout. ## How did you test it? - [x] built - [x] covered by existing tests - [x] added new unit test(s) — `replication_reader_group_test.go` covers reader-ID derivation, catch-up watermark lookup for all scope formats, reader-state construction (tiered and single-stack, including mismatched-mode errors), failover watermark selection, and the exact 3-vs-4-scope boundary in both flag positions - [x] added an equivalence test — `TestRecvSyncReplicationState_ReaderGroupEquivalence` runs the same ack through both flag branches and asserts the persisted `QueueReaderState` and failover watermark are identical ## Potential risks The refactored path is flag-gated and default-off; the default path is byte-for-byte the previous logic (pinned by the equivalence test), so risk is limited to enabling the flag. The flag-change stream restart mirrors the existing tiered-stack flag behavior. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- > [!NOTE] > **Medium Risk** > Touches replication stream sender cursor and failover watermark logic, which is core multi-cluster infrastructure, but the new path is default-off and equivalence-tested against the legacy path. > > **Overview** > Extracts the stream sender's per-priority `QueueReaderState` arithmetic into a new `replicationReaderGroup`, gated by **`EnableReplicationReaderGroup`** (default off). > > Catch-up watermark lookup, reader-state construction from `SyncReplicationState` acks, and failover watermark selection now live behind this abstraction. Scope-index mapping is centralized in `priorityScopeIndex`, which keeps the legacy exactly-3-scopes behavior when the flag is off and only tolerates >3 scopes on the new path (for upcoming namespace-isolation lanes). > > Flag flips restart replication streams, matching the existing tiered-stack flag pattern. Equivalence tests pin that both paths persist identical reader state and failover watermarks. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit bd89ff0903d6f85c579795be7142785f86997619. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot). ", "url": "https://github.com/temporalio/temporal/pull/11302", "timestamp": "2026-08-12T13:28:42Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation", "reliability-2026" ], "author": "robholland", "assignees": [], "change": "new" }, { "id": "github:temporalio/temporal:pull_request:11303", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add replication stream lane wire protocol and receiver-side lane routing", "text": "> **Part 3 of a 5-PR series** building to replication stream namespace isolation (a restructuring of #10147): read buffer → reader group → lane protocol → isolation manager → sender isolation. > #11302 (reader group) has merged, so this PR's diff is now standalone against `main`. · **Next in series: #11304** (isolation manager). ## What changed? The wire-level building blocks for per-namespace lane isolation, receiver side only: - **Proto**: `SyncReplicationState` gains `pause_high_namespace_ids` (namespaces the receiver reports as overwhelming the HIGH lane — the priority lives in the field name, so a future LOW extension adds its own field rather than widening this one), `isolated_lane_states` (per-lane applied watermarks keyed by namespace ID — with the documented caveat that a missing key is ambiguous between \"not tracked yet\" and \"retired and drained\", so a sender must never treat absence alone as drain proof), and `supports_namespace_isolation` (capability advertisement, so a sender never emits lane-tagged traffic to a receiver that would misroute it). `WorkflowReplicationMessages` gains `isolated_namespace_id` — when set, the batch belongs to that namespace's dedicated lane — and `retire_isolated_lane`, marking a lane's final message. - **Receiver**: lane-tagged batches route to lazily-created per-namespace task trackers. Each lane is its own monotonic stream for the life of the connection — there is no rewind or rotation machinery, because the sender-side design (later in the series) gives every lane a single owner cursor that never goes backwards. Member-lane watermarks fold into the overall ack minimum (cleanup safety) and are reported per lane; member-lane backlogs count toward HIGH flow control. Lane lifecycle is defensive about ordering: a batch's tasks are tracked BEFORE its retire flag is applied (so the concurrent ack loop can never delete a lane whose final batch is mid-track), a retiring lane is only dropped once it is drained AND has tracked at least one batch, and non-retire traffic arriving on a retiring lane revives it (the sender re-isolated the namespace before the lane drained). Lane-tagged traffic at any priority other than HIGH is a protocol violation and fails the stream rather than silently mis-acking (isolation splits the HIGH lane only). Lanes created concurrently with `Stop()` are pre-cancelled so no tasks run after shutdown. - **`NamespaceThrottler`** interface (default: noop, via fx) observes per-namespace HIGH-priority task load and decides which namespaces to report. The sender does not tag lanes yet, so this is inert until the sender-side isolation lands. ## Why? Isolation needs a wire contract before the sender can use it: capability advertisement, per-lane routing and progress reporting, and the throttled-namespace feedback channel. Landing the receiver first makes mixed-version clusters safe by construction. Compared to #10147, lanes are per-namespace rather than shared per severity tier — which is what eliminates that design's cursor rewinds and the watermark-regression/tracker-rotation protocol this PR previously needed to compensate for them. ## How did you test it? - [x] built - [x] covered by existing tests - [x] added new unit test(s) — lane routing (priority routing when unset, per-namespace tracker identity, non-HIGH rejection), retirement lifecycle (drop once drained, never-tracked retiring lane survives the ack snapshot, revive on re-isolation traffic, fresh lane after drop), and post-Stop lane creation being pre-cancelled - [x] added new functional test(s) — exercised end-to-end by the xdc test in the final PR of the series ## Potential risks Inert until a sender emits `isolated_namespace_id`, which is gated behind both a config flag and the capability advertisement. Receiver-side lane state is bounded by the sender's isolation cap (final PR). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- > [!NOTE] > **Medium Risk** > Touches replication ack watermarks and stream failure modes in tiered-stack mode, but lane traffic is unused until the sender ships and default throttler is noop. > > **Overview** > Adds the **wire contract and receiver-side behavior** for per-namespace replication stream isolation (sender lane tagging lands in a follow-up PR). > > **Proto** extends `SyncReplicationState` with `pause_high_namespace_ids`, per-namespace `isolated_lane_states`, and `supports_namespace_isolation`. `WorkflowReplicationMessages` gains `isolated_namespace_id` and `retire_isolated_lane` for lane-tagged batches and lane teardown. > > **Stream receiver** routes lane-tagged HIGH batches to lazily created per-namespace trackers, folds member-lane watermarks into the overall ack minimum, counts member-lane backlog in HIGH flow control, and reports throttled namespaces via a new **`NamespaceThrottler`** hook (default noop in fx). Tiered-stack acks advertise isolation support; non-HIGH lane-tagged traffic fails the stream. > > Behavior is **inert** until a sender sets `isolated_namespace_id`; existing streams unchanged. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit b839cba487a681767dbe799bd66d3694b995beb5. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot). ", "url": "https://github.com/temporalio/temporal/pull/11303", "createdAt": "2026-07-27T12:22:32Z", "updatedAt": "2026-08-13T16:35:29Z", "timestamp": "2026-08-13T16:35:29Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation", "reliability-2026" ], "author": "robholland", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11304", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add isolation manager for per-namespace replication lanes", "text": "> **Part 4 of a 5-PR series** building to replication stream namespace isolation (a restructuring of #10147): read buffer → reader group → lane protocol → isolation manager → sender isolation. > **Stacked on #11303** (lane wire protocol). This PR targets `main`, so until the earlier PRs in the series merge its diff also includes their commits — review after they land. · **Next in series: #11305** (sender isolation). ## What changed? `isolationManager`: the sender-side state machine for HIGH-lane namespace isolation. Each namespace the receiver reports as overwhelming the shared HIGH (live) lane is split onto its own dedicated lane — an independent read cursor and wire stream, paced by a throttled severity tier (a rate class). Because every member owns its cursor: - members never interact — joining, demoting, or graduating one namespace moves no other namespace's position; - **no cursor ever rewinds**, so there is no CAS machinery, no rewind-point arithmetic, and no receiver-side tracker rotation (all of which the shared-tier-cursor design in #10147 required); - demotion is purely a rate-class change that moves no data. Lane transitions still anchor on applied (acked) watermarks so ordered HIGH events never straddle a hand-off with a gap: a split floors the member at the shared lane's acked watermark, and graduation is gated on the member's lane having applied up to the shared cursor — and never fires while the shared cursor is still unknown (0), which would make the gate vacuous. Graduated members are queued for the send loop to emit a lane-retirement marker; a re-split cancels any not-yet-emitted marker (it would retire the NEW lane). **Lane generations:** each lane incarnation carries a generation number, because a namespace can graduate and later re-split. Cursor advances are generation-checked, so a tier loop finishing a batch from before a graduation can never fast-forward the new incarnation's cursor past tasks it hasn't sent (the classic ABA hazard). Member acked watermarks are monotonic — a stale receiver report can't rewind a persisted resume point. Member scopes reuse the multi-cursor queue framework (`queues.Scope`, `tasks.NamespacePredicate`), and the persisted reader-state codec round-trips through `queues.ToPersistenceScope`/`FromPersistenceScope`: scope 0 = overall min, 1 = shared HIGH excluding isolated namespaces, 2 = LOW, 3+ = one scope per member resuming at its applied watermark. **Scope 0 is clamped to the minimum over member resume positions**: replication task cleanup deletes strictly below `Scopes[0]` and reads no other scope, while the receiver's folded watermark cannot vouch for windows its connection has never seen (e.g. right after a reconnect, before member lanes re-form) — without the clamp, cleanup could delete a restored member's unsent window. The isolated set is capped by `maxIsolated`; restored members are kept above a lowered cap (dropping them would gap their lanes), severity resets to tier 1 on reconnect, and config inputs are clamped to sane minimums (tierCount ≥ 1 etc.) so misconfiguration cannot strand namespaces. State machine only; the stream sender is wired to it in the next PR. ## Why? This is the heart of the design, reviewable in isolation as a pure, unit-tested state machine. The per-member-lane shape is what the shared read-through buffer (first in the series) makes affordable — per-lane scans at the tip are in-memory passes — and in exchange the entire rewind/rotation protocol of the shared-cursor design disappears. ## How did you test it? - [x] built - [x] added new unit test(s) — split floors and lane scopes, member independence, the isolation cap (including slot reuse after graduation), demotion as a rate-class change capped at the deepest tier, merge-back gating on applied watermarks with cooldown and re-throttle reset (including never graduating against an unset shared cursor), retirement queueing and re-split cancellation, generation-checked and monotonic cursor advances, monotonic acked watermarks, the scope-0 cleanup clamp, config clamping, and a persistence round-trip including legacy 3-scope states ## Potential risks No production code paths reference the manager yet (wired next PR), so this PR is behaviorally inert. Merge-back remains best-effort: a calm namespace stays isolated while its lane lags the gate — harmless while calm, reset by any reconnect. The scope-0 clamp pins replication task cleanup at the slowest member lane's resume position; that retention is bounded by the lane's tier pacing and is exactly the window cleanup must not delete. 🤖 Generated with [Claude Code](https://claude.com/claude-code)", "url": "https://github.com/temporalio/temporal/pull/11304", "createdAt": "2026-07-27T12:22:34Z", "updatedAt": "2026-08-13T16:21:07Z", "timestamp": "2026-08-13T16:21:07Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation" ], "author": "robholland", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11313", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Track process-lifetime object leak baselines", "text": "## What changed? The `objectleak` package has no support for establishing a baseline; therefore it erroneously reports false positives. ## Why? Ensure `objectleak` report is actionable and insightful.", "url": "https://github.com/temporalio/temporal/pull/11313", "createdAt": "2026-07-27T18:52:47Z", "updatedAt": "2026-08-12T16:39:57Z", "timestamp": "2026-08-12T16:39:57Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "stephanos", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11355", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Preserve logger tags across Skip()", "text": "## What changed? `zapLogger.Skip()` now carries the logger's accumulated `tags` into the returned clone, matching the `baseZl` field it already forwarded. Also updated `TestThrottleLogger` to apply a `service` tag *before* the throttled logger wraps it, mirroring what `ThrottledLoggerProvider` does. ## Why? Tags applied before a `Skip()` were silently dropped by the next `With()` call. This regressed in #7945. Before that PR, `With()` did `l.zl.With(fields...)`, so accumulated tags lived inside the zap logger itself — `Skip()` copied `zl`, and the tags came along for free. #7945 changed `With()` to rebuild from the untagged `baseZl` using a new `tags` slice, which made that slice the only surviving record of accumulated tags. `Skip()` was updated to forward the new `baseZl` field but not the new `tags` field, so any `With()` on a Skip'd logger rebuilt from the untagged base and lost everything applied earlier. **Observed on a running server.** Two builds (with and without the fix) started via `make start`, startup logs diffed by `(msg, logging-call-at)` rather than line order. 0/8 Started Worker lines included the service field without the fix, 8/8 with it. Prior to this fix: ````{\"level\":\"info\",\"ts\":\"2026-07-30T08:28:49.544-0700\",\"msg\":\"Started Worker\",\"Namespace\":\"temporal-system\",\"TaskQueue\":\"temporal-sys-tq-scanner-taskqueue-0\",\"WorkerID\":\"temporal-system@127.0.0.1:7239\",\"logging-call-at\":\".../go/pkg/mod/go.temporal.io/sdk@v1.44.0/internal/internal_worker.go:1425\"}```` With the fix: ````{\"level\":\"info\",\"ts\":\"2026-07-30T09:03:02.318-0700\",\"msg\":\"Started Worker\",\"service\":\"worker\",\"Namespace\":\"temporal-system\",\"TaskQueue\":\"temporal-sys-tq-scanner-taskqueue-0\",\"WorkerID\":\"temporal-system@127.0.0.1:7239\",\"logging-call-at\":\".../go/pkg/mod/go.temporal.io/sdk@v1.44.0/internal/internal_worker.go:1425\"}```` Note that `Namespace`, `TaskQueue`, and `WorkerID` are applied by the SDK via `With()` *after* the `Skip()` and survive in both builds, whereas `service` is applied *before* it and hence it is the only field missing. `SdkClientFactoryProvider` wraps `SnTaggedLogger` via `NewSdkLogger`, which calls `Skip()`, and SDK client logs lose `service` when `With()` is called on the supplied logger. `ThrottledLoggerProvider` wraps the same `SnTaggedLogger` identically and loses `service` the same way; that path is what the updated `TestThrottleLogger` covers. `NewReplayLogger` also wraps the same way and is also fixed by the same change, though it has no call sites in this repo. No existing test caught it because `TestThrottleLogger` applied no tags before the `Skip()`, so it passed identically either way. ## How did you test it? - [x] built - [x] run locally and tested manually - [ ] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) ## Potential risks - Log output changes: lines from Skip-wrapping loggers (throttled, SDK, replay) that go through `With()` will now include tags that have been missing since #7945 — most visibly `service`. Anything parsing these logs by exact field set, or alerting on `service` being absent, will see different output. This fix restores pre-#7945 behavior rather than introducing something new.", "url": "https://github.com/temporalio/temporal/pull/11355", "createdAt": "2026-07-30T16:29:05Z", "updatedAt": "2026-08-13T06:35:12Z", "timestamp": "2026-08-13T06:35:12Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "geraldw-ai", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11380", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Recognize the new `commonpb` Worker callback variant", "text": "⚠️ This is part of a stacked PR set, to be merged into `feature/worker-callbacks`. This will not go directly into `main`, until the overall feature is code complete. --- ## What changed? The worker callbacks feature introduces a new variant of `commonpb.Callback` to describe callbacks for invoking a Nexus operation on a waiting worker. This PR adds the support for recognizing this new kind of callback in the CHASM code, but does not implement any sort of support. (Supplying a worker callback to a standalone Activity or workflow will result in an error.) ## Why? Part of the overall worker callbacks feature. ## How did you test it? - [x] built - [x] run locally and tested manually - [x] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) ## Potential risks Nothing I can think of.", "url": "https://github.com/temporalio/temporal/pull/11380", "createdAt": "2026-07-31T20:25:45Z", "updatedAt": "2026-08-12T17:03:50Z", "timestamp": "2026-08-12T17:03:50Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "chrsmith", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11397", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Fix constant/error-dependent retry jitter being truncated to a no-op", "text": "## What changed? `addJitter` in `common/backoff/retrypolicy.go` never applied jitter. With a 2s base and `WithJitter(0.1)`, every delay came back as exactly 2.000s instead of spread across `[2.0s, 2.2s)`. ```go // before return duration * time.Duration(1+jitterPct*rand.Float64()) // after return time.Duration(float64(duration) * (1 + jitterPct*rand.Float64())) ```` `1 + jitterPct*rand.Float64()` is a `float64` in `[1.0, 2.0)` for any `jitterPct < 1.0`. Wrapping it in `time.Duration(...)` truncates it to the `integer` 1 _before_ the multiply, so the whole expression collapsed to `duration * 1`. The fix does the arithmetic in float space and converts once at the end, where truncation only drops sub-nanosecond fractions. This free function serves `ConstantDelayRetryPolicy.ComputeNextDelay` and `ErrorDependentRetryPolicy.ComputeNextDelay`. **`ExponentialRetryPolicy` is not affected** — it has its own separate `addJitter` method that works entirely in float space and is correct. Three tests exercised jitter and all three passed against the bug: each asserted `delay >= base && delay < ceiling`, and the buggy value is exactly `base` — the admitted lower bound. Each also took a single sample. All three now sample 1000× and require at least one delay strictly above base, with upper bounds tightened to the true `base*(1+jitterPct)`. `TestAddJitter` also pins `addJitter(d, 0) == d`. ## Why? `WithJitter` is a public builder method that silently did nothing when used as documented. **Latent — no production effect today.** `WithJitter` only writes `p.jitterPct`, which defaults to 0, and at 0 the old and new forms are identical. Its only two call sites are in `retrypolicy_test.go`; `ErrorDependentRetryPolicy` is never constructed outside tests, and `ConstantDelayRetryPolicy`'s one production construction (`namespaceQueueRetryPolicy`, `common/persistence/client/factory.go`) doesn't call it. ## How did you test it? - [x] built - [ ] run locally and tested manually - [x] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) Reverted the fix and confirmed all three strengthened tests fail against the original code (`jitter was never applied; delay stayed at the base value`), then restored it and confirmed that the tests pass. ## Potential risks Low. The change is one line plus test assertions, and it is a no-op at `jitterPct == 0`, which is every production call site today (see above) — so nothing in the server's retry timing moves. Where jitter is enabled, delays now vary within `[base, base*(1+jitterPct))` rather than being pinned to `base` — intended, but it would surface in anything that had come to rely on the constant value. Only the tests changed here did.", "url": "https://github.com/temporalio/temporal/pull/11397", "createdAt": "2026-08-02T14:22:00Z", "updatedAt": "2026-08-13T06:35:10Z", "timestamp": "2026-08-13T06:35:10Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "geraldw-ai", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11400", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "VLN-1587: remediate claude-code-action-unhardened", "text": "> 🏕️ This pull request was created by [camper](https://github.com/temporalio/camper), an automated security campaign tool. ## Finding
Ruleclaude-code-action-unhardened
SeverityMEDIUM
Repositorytemporalio/temporal
TicketVLN-1587
## Summary - `.github/workflows/claude-review-teams.yml`: Pinned `anthropics/claude-code-action` to the vetted v1.0.183 commit, disabled full output logging, disabled checkout credential persistence, and added Claude web-tool and turn limits while preserving the review bot's scoped PR review tooling. ## Instructions - **Approve** to merge this fix - **Request changes** to trigger a new remediation attempt - `/camper rebase` — rebase onto the base branch - `/camper close` — close this PR without merging - `/camper retry` — regenerate the fix from scratch against the current base", "url": "https://github.com/temporalio/temporal/pull/11400", "createdAt": "2026-08-03T14:19:40Z", "updatedAt": "2026-08-12T14:02:38Z", "timestamp": "2026-08-12T14:02:38Z", "metrics": { "reactions": 1, "comments": 2 }, "labels": [], "author": "picatz", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:temporalio/temporal:pull_request:11401", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Emit handover watermark and shard readiness wide events", "text": "## What changed? Adds `NamespaceLifecycle` wide events on the two paths that decide when a namespace handover can complete. Also threads `ShardID` and an `EventLogger` into `HandoverTrackerParams` so the tracker can attribute an event to its shard. **Shard handover tracker** (`service/history/shard/`) — each shard holds its own replication watermark for a namespace in handover, and the handover cannot complete until every shard's watermark has been acked by the target: | Phase | When | |---|---| | `shard_handover_watermark_set` | the shard takes or advances a watermark — `reason` is `added` or `updated` | | `shard_handover_watermark_removed` | the shard drops it — `deleted_from_db` separates a namespace deletion from a normal exit out of handover | Both fire only on an actual mutation of the tracker map. Notably, the non-handover branch of `UpdateHandoverState` runs for *every* namespace notification on *every* shard; it now guards on presence before deleting, so it emits only on a real removal rather than on every notification. **`WaitHandover`** (`service/worker/migration/`) — one event, emitted on the way out: | Phase | When | |---|---| | `shard_handover_incomplete` | the wait ended with shards still behind | Carries `not_ready_count`, `total_shards`, `missing_handover_info_count`, `max_lagging_tasks{,_shard_id}`, `elapsed_seconds`, `exit_reason`, and a `lagging_shards` list of `{shard_id, lagging_tasks}` capped at 64 (`not_ready_count` is always the true count). A handover that completes leaves no laggards and emits nothing, so the happy path — nearly all of them — is silent. The wait is capped at `maximumHandoverTimeoutSeconds` (30) with `MaximumAttempts: 1`, so this is at most one event per handover. `exit_reason` separates the wait being killed while shards were still behind from a failed `GetReplicationStatus`. The activity never returns on its own in the former case: the SDK cancels the activity context off the heartbeat, the next `GetReplicationStatus` fails, `WaitHandover` returns, and the deferred summary runs. A not-ready shard with `lagging_tasks == 0` is the missing-handover-info case (that shard's namespace cache hasn't picked up the handover yet); any other not-ready shard is behind by `lagging_tasks`. ## Why? When a handover stalls, the only signal today is `Wait handover not ready`, which reports counts plus the single worst shard, once a second for the life of the wait. That is not enough to name the shards actually holding it up, or to tell a shard that never took a watermark from one whose watermark is not being acked. These events make both attributable, and the summary form costs one row per failed handover instead of one log line per second. Emission is a no-op unless a `LoggerProvider` is configured, so there is no cost for deployments that have not opted in. ## How did you test it? - [x] covered by new unit tests - [x] built New tests pin the behavior that keeps these off the hot path: - `TestHandoverWatermarkRemovedOnlyWhenTracked` — the per-notification branch emits nothing when there is no watermark to remove. - `TestHandoverWatermarkEvents` — set/update/remove, and that a repeat notification at the same version emits nothing. - `TestHandoverWatermarkPendingThenResolved` — the unacquired-shard sentinel is reported as `pending`, and resolving it on acquire emits nothing. - `TestEmitHandoverLagSummarySilentWhenReady` — a completed handover emits nothing. - `TestCheckHandoverOnceSnapshotIsLastPollOnly` — the snapshot is overwritten per poll, so laggards from an earlier poll cannot leak into the summary. - `TestEmitHandoverLagSummaryNamesLaggingShards` / `ExitReason` / `Truncates` — payload contents, exit-reason classification, and the per-shard cap. `go test ./service/history/shard/... ./service/worker/migration/...` passes; `go vet` and `gofmt` clean.", "url": "https://github.com/temporalio/temporal/pull/11401", "createdAt": "2026-08-03T15:01:23Z", "updatedAt": "2026-08-13T02:00:50Z", "timestamp": "2026-08-13T02:00:50Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation", "reliability-2026" ], "author": "michaely520", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11413", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Persist Callback terminal failures", "text": "⚠️ This is part of a stacked PR set, to be merged into `chrsmith/wc-add-worker-cb-variant`. This will not go directly into `main`. --- ## What changed? Add a new field to the CHASM Callback component to persist the terminal failure of a CHASM Callback. The [CallbackState](https://github.com/temporalio/temporal/blob/main/chasm/lib/callback/proto/v1/message.proto#L11) that includes a `last_attempt_failure` field which is set whenever there is a delivery error. This would contain the terminal failure for the CHASM callback as long as the _only_ way the callback could fail is due to a non-retryable delivery. (And not a cancellation, timeout, etc.) We now have a separate `TerminalFailure` field, stored separately than the `last_attempt_failure`. (This is to avoid growing the size of the persisted `CallbackState` proto, as well as reducing the size of database writes since the `TerminalFailure` will only be written once.) ## Why? Currently, there is no need for this field. Because it is not possible to cancel a CHASM Callback, or for it to timeout, the terminal failure can be _inferred_ by referencing the `last_attempt_failure`. However, we will want CHASM Callbacks to support \"external\" failures. If not for the worker callbacks feature, then for manual completions down the road. Also, it avoids any confusion or ambiguity about whether `last_attempt_failure` is the _terminal_ failure, or just the last (retryable) delivery error. ## How did you test it? - [x] built - [x] run locally and tested manually - [x] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) ## Potential risks - Adding a new CHASM field can be tricky, because when loading existing CHASM components the field may-or-may-not be present. In this case, we fall back to `last_attempt_failure` if `TerminalFailure` is not present, which is sufficient. - If a CHASM component is persisted with the new `TerminalFailure` field, and then the server is _downgraded_, the next write for the CHASM component will _delete_ the \"unknown\" `TerminalFailure` field. Because of the fallback to `last_attempt_failure`, this too is accounted for.", "url": "https://github.com/temporalio/temporal/pull/11413", "createdAt": "2026-08-04T17:20:01Z", "updatedAt": "2026-08-12T21:50:24Z", "timestamp": "2026-08-12T21:50:24Z", "metrics": { "reactions": 0, "comments": 9 }, "labels": [], "author": "chrsmith", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11415", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add completion callbacks to SANOs", "text": "⚠️ This is part of a stacked PR set, to be merged into `chrsmith/wc-persist-callback-terminal-failures`. This will not go directly into `main`, until the overall feature is code complete. --- ## What changed? The API surface area for the worker callbacks feature adds a new `completion_callbacks` field to SANOs, allowing users to register callbacks to be executed when the SANO completes. (Just like standalone Activities.) This PR implements that feature for SANO, allowing completion callbacks to be added, executed, and for their status to be reported by the `DescribeNexusOperationExecution` endpoint. However, this new capability is guarded by a per-namespace dynamic config value `\"nexusoperation.enableNexusCallbacks\"`. Attempts to attach worker callbacks to SANO will fail, and namespaces will need to opt-into using this new feature. ## Why? This is part of the overall worker callbacks feature. (With worker callbacks being a specific kind of completion callback you can attach to SANO.) Worker-variant callbacks are still not supported in this PR. Only Nexus- and Internal- variant callbacks will be accepted, if the feature is enabled. ## 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 - It's essentially a new feature, and so there are lots of edge cases we need to consider. For example, that repeated calls to `Start-` are idempotent. That the `on_conflict_options` are honored, etc. Otherwise, we run the risk of SANO being slightly inconsistent with how completion callbacks work for standalone Activities. > I added a comment to call out a minor bug in standalone Activities. It's already on the ACT team's radar. On the [SAA bugs punch list](https://app.notion.com/p/temporalio/SAA-bug-claims-3a08fc5677388009a690cff570aeaa45?source=copy_link). > \"FT C9. On-conflict callback attachment is not idempotent or atomic\"", "url": "https://github.com/temporalio/temporal/pull/11415", "createdAt": "2026-08-04T17:28:53Z", "updatedAt": "2026-08-12T22:54:47Z", "timestamp": "2026-08-12T22:54:47Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "chrsmith", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11419", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Improve flaky-test report collection and bisecting", "text": "## What changed? - Add a rate-limited GitHub API client for efficiently retrieving workflow, artifact, and commit data. - Aggregate test runs once and reuse the index for report generation and bisect analysis. - Add parallel processing and coverage for API handling, aggregation, parsing, and report/bisect behavior. ## Why? The flaky-test report needs to process a large workflow history without redundant work or exceeding GitHub API limits. ## How did you test it? - [x] added new unit test(s) - [x] checked the diff for whitespace errors - [ ] built - [ ] run locally and tested manually - [ ] covered by existing tests - [ ] added new functional test(s) ## Potential risks GitHub API changes may still encounter unexpected response or rate-limit behavior at production scale; the client applies bounded concurrency, retries, and cooldowns.", "url": "https://github.com/temporalio/temporal/pull/11419", "createdAt": "2026-08-04T23:31:25Z", "updatedAt": "2026-08-13T02:17:27Z", "timestamp": "2026-08-13T02:17:27Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "chaptersix", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11422", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Skip unbuildable replication tasks on stream sender instead of blocking", "text": "## What changed? Skip unbuildable replication tasks on stream sender instead of blocking the stream. The skip is logged and new metric ReplicationTaskSendSkipped added. ## Why? When the replication stream sender cannot build (\"convert\") a task, it retries and, once the retry budget is exhausted, returns an error that tears the stream down. On reconnect the sender resumes from the same watermark, hits the same unbuildable task, and blocks the whole shard's stream indefinitely. This change skips the task to unblock and logs, add a metric for the skipped task so that it could be investigated later. ## How did you test it? - [x] built - [x] run locally and tested manually - [ ] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s)", "url": "https://github.com/temporalio/temporal/pull/11422", "createdAt": "2026-08-05T15:53:14Z", "updatedAt": "2026-08-13T15:42:36Z", "timestamp": "2026-08-13T15:42:36Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation", "reliability-2026" ], "author": "qyc5937", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11439", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Detect incompatible metric schemas in mixed-brain tests", "text": "## What changed? - Give the current and previous-release mixed-brain servers separate Prometheus endpoints. - Scrape both endpoints after the OMES workload and fail on inconsistent label sets within either server or incompatible label sets across versions. - Require `task_requests` coverage and narrowly allowlist label additions that already exist between the current and previous release. - Add focused unit coverage for incompatible, internally inconsistent, compatible, and allowlisted schemas. ## Why? A metric whose label count changes across mixed server versions can be rejected by the Cloud metrics handler, dropping that metric and potentially hiding alerts. Running this check in the existing Temporal PR mixed-brain test catches those compatibility regressions before merge. ## How did you test it? - [ ] built - [x] run locally and tested manually - [ ] covered by existing tests - [x] added new unit test(s) - [x] added new functional test(s) `go test -tags test_dep . -run '^TestMetricSchemaProblems' -count=1` `MIXED_BRAIN_TEST_DURATION=30s PERSISTENCE_DRIVER=postgres12 TEST_OUTPUT_ROOT=/tmp/temporal-mixedbrain-metric-schema-clean go test -tags test_dep . -run '^TestMixedBrain$' -count=1 -timeout 15m -v` The end-to-end run passed against the current source and previous release tag `v1.31.2`. ## Potential risks The scan covers metric series emitted by the OMES workload; metrics not exercised during the run are not compared. The metric-specific allowlist accepts only the exact known one-label additions and may need deliberate maintenance as old compatibility exceptions age out. Lint was not run.", "url": "https://github.com/temporalio/temporal/pull/11439", "createdAt": "2026-08-06T16:24:40Z", "updatedAt": "2026-08-13T00:43:53Z", "timestamp": "2026-08-13T00:43:53Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "chaptersix", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11446", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Reorganize CHASM activity codebase", "text": "## What changed? - Reorganize `chasm/lib/activity` ## Why? - Improve navigability and codebase comprehensibility ## How did you test it? - [x] covered by existing tests", "url": "https://github.com/temporalio/temporal/pull/11446", "createdAt": "2026-08-07T18:22:04Z", "updatedAt": "2026-08-12T18:25:53Z", "timestamp": "2026-08-12T18:25:53Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "dandavison", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11450", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Enable host level events cache by default", "text": "## What changed? Flip the default of `history.enableHostLevelEventsCache` from `false` to `true`, so history shards share a single host-level events cache instead of each allocating a shard-level one. ## Why? We have been using host level history cache for a while. We can now enable it in code by default. ## How did you test it? - [x] built - [x] covered by existing tests", "url": "https://github.com/temporalio/temporal/pull/11450", "createdAt": "2026-08-09T03:52:24Z", "updatedAt": "2026-08-12T20:38:23Z", "timestamp": "2026-08-12T20:38:23Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "reliability-2026" ], "author": "prathyushpv", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11456", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add support for worker-variant callbacks", "text": "## What changed? This PR updates the CHASM `Callback` component to support the new `Worker`-variant. Unlike `Nexus` callbacks, which just issue an HTTP `POST` request to deliver a Nexus completion result (and potentially in another namespace), these new `Worker` callbacks are for invoking a Nexus operation within the same namespace. This PR does _not_ enable Worker callbacks anywhere. It just adds the underlying capability. (The next PR in the stack will allow you to enable worker callbacks for SANOs.) ## Why? This is the actual support for the worker callbacks feature, enabling the end-to-end scenario. Worker callbacks as a capability will make it easier to implement so-called Nexus Connectors, where you expose a Nexus service from a non-Nexus protocol. (e.g. having a REST HTTP server act as a gateway for Nexus operations.) ## How did you test it? - [x] built - [x] run locally and tested manually - [x] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) ## Potential risks 🤔", "url": "https://github.com/temporalio/temporal/pull/11456", "createdAt": "2026-08-10T16:59:54Z", "updatedAt": "2026-08-12T22:44:52Z", "timestamp": "2026-08-12T22:44:52Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "chrsmith", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11458", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Close SQLite databases with their owners", "text": "## What changed? Properly close SQLite connection and database. ## Why SQLite previously retained one shared connection pool per DSN for the entire process. Each SQL factory now owns an initial reference while its stores borrow additional references. Closing the final factory releases the connection pool without losing an in-memory database when shorter-lived stores close.", "url": "https://github.com/temporalio/temporal/pull/11458", "createdAt": "2026-08-10T20:53:04Z", "updatedAt": "2026-08-12T16:39:56Z", "timestamp": "2026-08-12T16:39:56Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11459", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Record what a replication task carried on the sent lifecycle event", "text": "A `sent` event records that a task went out, not *what it carried* — and that can't be recovered afterwards. `LastUpdateVersionedTransition` stamps are overwritten by later transitions, and the replication progress cache that supplies the lower bound of both the state diff and the event range is in-memory and per `(run, target)`. Seven sent-only fields: - `target_cluster` — scopes the bounds, since progress is cached per target - `priority` — the stream the task went out on - `artifact_kind` — snapshot vs mutation - `exclusive_start_versioned_transition` — the mutation's exclusive lower bound - `hydrated_versioned_transition` — the versioned transition of the state actually serialized - `shipped_first_event_id` / `shipped_last_event_id` — the event ids actually carried Note `hydrated_versioned_transition` is `>=` the task's own versioned transition whenever the sender advanced past the queued task, so the existing `transition_count` describes the queue entry while this describes the payload. Likewise `shipped_*_event_id` are the events carried, distinct from `first_event_id`/`next_event_id`, which are the task's own range. `priority` is only known to the sender: it is assigned per send loop, and only the low-priority stream is rate limited, while flow control, trackers and ack watermarks are all per priority. Without it a backed-up stream can't be attributed. Also populates `failover_version`/`transition_count` on the `sync_versioned_transition` applied event; the `!= 0` guard dropped them, leaving sent→applied uncorrelatable. All values are read from the task at the existing emit site, so no interfaces change and the send path is untouched. Everything stays behind `history.emitReplicationLifecycleEvents`. Verified end-to-end against a live two-cluster replication stream. 🤖 Generated with [Claude Code](https://claude.com/claude-code)", "url": "https://github.com/temporalio/temporal/pull/11459", "createdAt": "2026-08-10T21:33:05Z", "updatedAt": "2026-08-13T02:01:07Z", "timestamp": "2026-08-13T02:01:07Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation", "reliability-2026" ], "author": "michaely520", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11461", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Standardize Claude review comments", "text": "Standardize Claude review comment format, style and focus.", "url": "https://github.com/temporalio/temporal/pull/11461", "createdAt": "2026-08-10T22:54:30Z", "updatedAt": "2026-08-13T14:54:05Z", "timestamp": "2026-08-13T14:54:05Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "stephanos", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11463", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Schedule v2 replay fidelity", "text": "## 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? - [ ] built - [ ] run locally and tested manually - [ ] covered by existing tests - [ ] added new unit test(s) - [ ] added new functional test(s) ## Potential risks _Any change is risky. Identify all risks you are aware of. If none, remove this section._", "url": "https://github.com/temporalio/temporal/pull/11463", "createdAt": "2026-08-10T23:31:02Z", "updatedAt": "2026-08-13T06:05:16Z", "timestamp": "2026-08-13T06:05:16Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "davidporter-id-au", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11464", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "NEXUS-504: Refactor Nexus frontend interceptors", "text": "## What changed? Refactoring Nexus frontend interceptors ## Why? https://temporalio.atlassian.net/browse/NEXUS-504 ## How did you test it? - [x] built - [x] run locally and tested manually - [x] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) ## Potential risks - [ ] Medium risk of regression, will be covered through tests", "url": "https://github.com/temporalio/temporal/pull/11464", "createdAt": "2026-08-11T00:50:02Z", "updatedAt": "2026-08-12T23:37:44Z", "timestamp": "2026-08-12T23:37:44Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "mavemuri", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11465", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add isolated functional test clusters", "text": "## Summary - give every testcore.NewEnv test a fresh cluster and tear it down with the test - bound concurrently live clusters to GOMAXPROCS by default, configurable with TEMPORAL_TEST_LIVE_CLUSTERS - preseed the primary and external namespaces for each cluster before server startup - preserve bounded legacy suite-owned cluster paths and suite-level worker-service requirements - retain lightweight optional JSONL lifecycle, boot-phase, runtime, and RSS reporting - build on #10643 for the lower-resource CI shard layout and its persistence prerequisites The shared pool, dedicated-cluster marker, warm spares, duplicate SQL/SQLite lease work, Cassandra reuse pool, and heavyweight report generator are intentionally removed from this PR. FASTBOOT.md retains the investigation history and current conclusions. ## Testing - make fmt lint - go test -race -tags=test_dep ./tests/testcore - go test -race -tags=test_dep ./tests -run ^TestClientDataConverterTestSuite$ -count=1 - go test -race -tags=test_dep ./tests -run ^TestWorkflowAliasSearchAttributeTestSuite$ -count=1", "url": "https://github.com/temporalio/temporal/pull/11465", "createdAt": "2026-08-11T02:58:59Z", "updatedAt": "2026-08-13T14:57:10Z", "timestamp": "2026-08-13T14:57:10Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "test-all-dbs" ], "author": "stephanos", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11470", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Jwt audience env config", "text": "## What changed? Added TEMPORAL_JWT_AUDIENCE to the embedded and Docker configuration templates, mapping the environment variable to global.authorization.audience. ## Why? JWT audience validation needs to be configurable in environment-based deployments, consistent with the existing JWT authorization settings. ## How did you test it? - [x] built - [ ] run locally and tested manually - [x] covered by existing tests - [ ] added new unit test(s) - [ ] added new functional test(s) ## Potential risks An incorrect TEMPORAL_JWT_AUDIENCE value can cause JWT-authenticated requests with a different audience to be rejected. When unset, it defaults to an empty value, preserving existing configuration behavior.", "url": "https://github.com/temporalio/temporal/pull/11470", "createdAt": "2026-08-11T05:31:35Z", "updatedAt": "2026-08-13T05:08:21Z", "timestamp": "2026-08-13T05:08:21Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "wtg-peternguyen", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11471", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Update test shard salt", "text": "Automatically generated by the optimize-test-sharding workflow.", "url": "https://github.com/temporalio/temporal/pull/11471", "createdAt": "2026-08-11T07:30:15Z", "updatedAt": "2026-08-13T07:33:14Z", "timestamp": "2026-08-13T07:33:14Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "temporal-cicd[bot]", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11474", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Reduce functional test scheduler worker counts", "text": "## What changed? Reduced worker counts in tests. ## Why? \"Screenshot", "url": "https://github.com/temporalio/temporal/pull/11474", "createdAt": "2026-08-11T14:56:41Z", "updatedAt": "2026-08-13T02:55:00Z", "timestamp": "2026-08-13T02:55:00Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "test-all-dbs", "reliability-2026" ], "author": "stephanos", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11479", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "replication: emit source_task_id and source_cluster on passive-side lifecycle events", "text": "## What Emits `source_cluster`, `source_shard`, and `source_task_id` on the `executing` and `applied` phases of the `replication_lifecycle` wide event, not just `sent`. ## Why `source_task_id` was already on the wire (`ReplicationTask.source_task_id`, populated at every `raw_task_converter.go` conversion site) and already stored on the task as `ExecutableTaskImpl.taskID` — which is also the watermark the receiver acks back. It was simply never emitted on the passive side, so a `sent` event on the active cluster could not be joined to the matching apply. Observability only: no proto change, no wire-format change, no version gating. ## Details - `common/wideevents`: added `SourceCluster` and `SourceShard`; moved `SourceTaskID` out of the sent-only group so all three are emitted phase-independently, guarded so they are absent when unset. - `common/wideevents/context.go`: `ReplicationTaskOrigin{ShardID, TaskID}` carries source provenance to the NDC `applied` emitter, which sits below the engine boundary and has no task in scope. Diagnostic only — never affects control flow. - Emitters populate the fields for `sync_versioned_transition`, `verify_versioned_transition`, and `sync_workflow_state`. **The join key is `(source_cluster, source_shard, source_task_id)` — the id alone is not unique.** Task ids are allocated per source shard from overlapping ranges. On a 4-shard xdc run with 6 workflows, 4 of 19 distinct `source_task_id`s appeared on more than one source shard, so this matters in any multi-shard deployment. The passive side gets the shard directly from `SourceShardKey()` (the stream receiver is created per source-shard pair); no reversal of `generateShardIDs` is involved, and that reversal would be ambiguous anyway when shard counts differ between clusters. `source_task_id` is intentionally absent on the two on-demand paths — the `SyncState` resend and child-completion verification — which re-fetch the artifact from the source, so the triggering task is not the one whose payload was applied. Emitting its id would create a false join. `source_shard` and `source_cluster` are still set on the resend path, since the source shard is known there. In queries, `applied AND source_task_id IS NULL` therefore isolates resend-originated applies. ## Test `go build ./...`, plus `common/wideevents`, `service/history/replication`, and `service/history/ndc` unit tests. `TestReplicationLifecycleFieldSetLocked` pins the new field set. Verified end to end on a two-cluster, 4-shard xdc harness (scaffolding not committed), asserting on every captured event that `source_shard` is present and non-zero, that it spans multiple distinct shards (so the assertion cannot pass on a constant), and that every passive `(source_shard, source_task_id)` pair matches a `sent` event the active side actually emitted on that shard: ``` source_shard present on all 71 replication_lifecycle events source_shard spans 3 distinct shards 4 sent source_task_ids appear on more than one source_shard (of 19 distinct ids) (source_shard, source_task_id) joined to a sent event on 48 passive events ``` Note there is no CI coverage that the emitters populate the fields — only that the payload can. Happy to add a unit test on payload construction if preferred. 🤖 Generated with [Claude Code](https://claude.com/claude-code)", "url": "https://github.com/temporalio/temporal/pull/11479", "createdAt": "2026-08-11T19:36:24Z", "updatedAt": "2026-08-13T02:01:25Z", "timestamp": "2026-08-13T02:01:25Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation", "reliability-2026" ], "author": "michaely520", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11480", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Extract shared JUnit XML handling", "text": "## What changed? Extract generic JUnit XML file reading and writing into `tools/common/junit`. ## Why? Centralizing format-level JUnit handling.", "url": "https://github.com/temporalio/temporal/pull/11480", "createdAt": "2026-08-11T20:57:07Z", "updatedAt": "2026-08-13T14:54:22Z", "timestamp": "2026-08-13T14:54:22Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "request-claude-review" ], "author": "stephanos", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11481", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Skip worker commands task queues in missing TQ check", "text": "## What Skip worker commands task queues (`temporal-sys/worker-commands/...`) when checking for missing task queues during version promotion (SetCurrent / SetRamping). ## Why An SDK bug caused version attributes to be set on worker commands queues, registering them in a deployment version. These queues are ephemeral and don't support versioning, so `IsVersionMissingTaskQueues` would incorrectly flag them as missing and block version promotion. ## How did you test it? Unit tests for `checkForMissingTaskQueues`: - Worker commands TQ in prev version is excluded from missing list - User TQ missing from new version is still reported - All TQs present returns empty", "url": "https://github.com/temporalio/temporal/pull/11481", "createdAt": "2026-08-11T22:22:30Z", "updatedAt": "2026-08-13T17:05:59Z", "timestamp": "2026-08-13T17:05:59Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "rkannan82", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11482", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Cleanup/consolidate completionHandler test infra", "text": "## What changed? When trying to clean up some PRs for worker callbacks, I noticed some unnecessary duplication and cruft in our testcases for completion handlers. Essentially it's this: \"image\" Rather than having N places where we construct a `completionHandler` and several implementations of spinning up an `httptest` webserver, we now just have a single `newNexusCompletionHandler` function that does both. ## Why? Remove boilerplate, making tests more concise and easier to read. ## How did you test it? - [x] built - [x] run locally and tested manually - [ ] covered by existing tests - [ ] added new unit test(s) - [ ] added new functional test(s) ## Potential risks If there was some subtle behavioral change this could undermine our testing.", "url": "https://github.com/temporalio/temporal/pull/11482", "createdAt": "2026-08-11T22:40:23Z", "updatedAt": "2026-08-13T02:02:03Z", "timestamp": "2026-08-13T02:02:03Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "chrsmith", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11483", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Reuse one persistence factory during server initialization", "text": "## What changed? Reuse a single persistence factory during server initialization. ## Why? Server initialization previously constructed and closed a separate persistence factory for each bootstrap operation. This also helps with https://github.com/temporalio/temporal/pull/11458 as this change ensures there's uninterrupted ownership of the sqlite database.", "url": "https://github.com/temporalio/temporal/pull/11483", "createdAt": "2026-08-11T22:45:49Z", "updatedAt": "2026-08-12T16:39:57Z", "timestamp": "2026-08-12T16:39:57Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "stephanos", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11486", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Fix approximateSize undercounting on activity start and heartbeat paths", "text": "## What changed? Fixed bookkeeping of mutable state approximate size on the two paths that mutate an `ActivityInfo` without adding its bytes to the counter: `AddActivityTaskStartedEvent` (start), and the heartbeat handler, where `RetryLastWorkerIdentity` now moves into `UpdateActivityProgress`. ## Why? Both sites mutate the pointer `GetActivityInfo` returned, but don't alter the approximate size. ## How did you test it? - [X] built - [ ] run locally and tested manually - [ ] covered by existing tests - [X] added new unit test(s) - [ ] added new functional test(s) ## Potential risks The risk should be low. We will hit the mutable state size limit faster, but it would be proper accounting.", "url": "https://github.com/temporalio/temporal/pull/11486", "createdAt": "2026-08-11T22:57:47Z", "updatedAt": "2026-08-13T15:41:50Z", "timestamp": "2026-08-13T15:41:50Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "reliability-2026" ], "author": "simvlad", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11487", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Separate test diagnostics and timeout parsing", "text": "Separates diagnostic parsing and timeout parsing into focused files without changing behavior. Existing comments and tests move with their implementations so the later canonical conversion is a semantic diff instead of a delete-and-add rewrite. Stack: depends on #11512. The canonical result model follows in #11514.", "url": "https://github.com/temporalio/temporal/pull/11487", "createdAt": "2026-08-11T23:31:23Z", "updatedAt": "2026-08-13T17:46:57Z", "timestamp": "2026-08-13T17:46:57Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11488", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Scope test diagnostics to canonical results", "text": "Converts test output analysis to package-aware canonical diagnostics and failure evidence. The existing runner reaches the new implementation through a temporary compatibility adapter, so there is still one parser implementation while the production cutover remains isolated. Stack: depends on #11514. The Go test JSON recorder follows in #11515.", "url": "https://github.com/temporalio/temporal/pull/11488", "createdAt": "2026-08-11T23:31:31Z", "updatedAt": "2026-08-13T17:47:05Z", "timestamp": "2026-08-13T17:47:05Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11492", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Stuartwells/gradual connect shedding tasks", "text": "## What changed? Adding support for a gradual connection period for globalized namespaces. This determines the start, step, and duration for ramp-up, during which a diminishing percentage of replication traffic will be shed (to be filled in via manual force-replicate at the end). ## Why? There are currently issues with clusters becoming overloaded during large migrations and potentially large globalizes. By ramping up the traffic, that gives more time for resources on the target cluster to scale up. ## 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) ## Potential risks This change drops tasks from the passive and intentionally engages a recovery mechanism. Potential gap I am testing against the most is ensuring the tasks are eventually propagated to the passive and not lost in the process. Force-replicate also needs to be manually initiated, so this leaves an opportunity for a gap if that is forgotten.", "url": "https://github.com/temporalio/temporal/pull/11492", "createdAt": "2026-08-12T01:20:47Z", "updatedAt": "2026-08-12T20:18:07Z", "timestamp": "2026-08-12T20:18:07Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stuart-wells", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11493", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "fix(activity): close standalone activity as TIMED_OUT instead of FAILED on worker-reported schedule timeout", "text": "## What changed? A worker reporting a schedule-to-start/close timeout via RespondActivityTaskFailed[ById] now closes a standalone (CHASM) activity as TIMED_OUT instead of FAILED, mirroring the timer-queue path and the workflow-activity behavior. The reported failure's Cause, if present, is preserved on the timeout outcome, otherwise prior attempt's failure is used as the cause. The specific changes are as follows: HandleFailed: route these timeouts to TransitionTimedOut timeoutEvent: add optional cause, preferred over the prior attempt's failure tests: parity coverage for the by-ID timeout and cause-preservation path ## Why? This is for parity with workflow activity, which was changed in PR #9132 to return retry state of TIMEOUT instead of NON_RETRYABLE_FAILURE when the schedule to close or schedule to start timeout causes the activity to close. In the case of standalone activity, the worker-reported schedule-to-start or schedule-to-close timeout should behave similarly. ## How did you test it? - [x] built - [ ] run locally and tested manually - [ ] covered by existing tests - [ ] added new unit test(s) - [x] added new functional/activity parity test(s)", "url": "https://github.com/temporalio/temporal/pull/11493", "createdAt": "2026-08-12T05:17:58Z", "updatedAt": "2026-08-13T05:05:11Z", "timestamp": "2026-08-13T05:05:11Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "ks-temporal", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11494", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "move admin batch jobs to sys ns", "text": "## What changed? - updated batch administration operations to run in the system namespace while continuing to use per-namespace task queues and workers. - allow batch activities running in the system namespace operating on other target namespaces - add ns to jobID and print all previous changes in tdbg prompts ## Why? to run refresh tasks in passive clusters of user global namespaces ## 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 need solid validation of the security for cross ns operation refer to analysis of this feature", "url": "https://github.com/temporalio/temporal/pull/11494", "createdAt": "2026-08-12T05:27:11Z", "updatedAt": "2026-08-12T18:12:37Z", "timestamp": "2026-08-12T18:12:37Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "feiyang3cat", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11500", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Enable Claude reviews for OSS Matching", "text": "## Summary - Enable automated Claude PR reviews for members of `temporalio/oss-matching`. ## Impact Members of the OSS Matching team will receive automated Claude reviews after the workflow's existing organization membership, repository permission, and label checks pass. ## Validation - `git diff --check` - Confirmed the branch contains a single workflow-only commit based on the latest `origin/main`. --- > [!NOTE] > **Low Risk** > Single workflow env change; no application or security logic is modified, only which GitHub team triggers an existing gated review job. > > **Overview** > Extends automated Claude PR reviews to **`temporalio/oss-matching`** by adding `oss-matching` to the `REVIEW_TEAMS` list in `.github/workflows/claude-review-teams.yml` (alongside existing `nexus` and `act`). > > PRs from active members of that team still go through the same eligibility path as other configured teams: org membership, repo write access, and no `skip-claude-review` label. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 86e1e13fd74a1afd781e690288d93e1a4e770956. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot). ", "url": "https://github.com/temporalio/temporal/pull/11500", "createdAt": "2026-08-12T13:32:52Z", "updatedAt": "2026-08-12T22:00:45Z", "timestamp": "2026-08-12T22:00:45Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "Shivs11", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11502", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Use chasm context NamespaceEntry instead of injecting namespace registry for activity code", "text": "## What changed? Updated the activity code to use a CHASM context API that was added after the original code was written. ## Why? Prevent this pattern from being copied to other libraries.", "url": "https://github.com/temporalio/temporal/pull/11502", "createdAt": "2026-08-12T15:38:14Z", "updatedAt": "2026-08-12T16:22:10Z", "timestamp": "2026-08-12T16:22:10Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "reliability-2026" ], "author": "bergundy", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11503", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Eliminate expected object leak suppressions", "text": "## What changed? - unregister process-global gRPC resolver and OpenTelemetry logger state during lifecycle shutdown - close the test matching client RPC factory and clear removed test references - let object checks wait for asynchronous shutdown cleanup while avoiding tiny-allocation false positives - remove every `WithExpected` entry from `objectLeakOpts` ## Why The leak test was suppressing the cluster graph instead of enforcing that cluster-owned objects become collectible. These lifecycle fixes leave only the process-lifetime baseline and the protobuf traversal prune. Stacked on #11458. The stack also includes #11483 and #11313. ## Testing - `make leak-test` (15 measured clusters: 0 expected, 0 unexpected retained objects) - focused tests for `common/testing/objectleak`, `common/membership`, `temporal`, and `tests/testcore` - `make lint`", "url": "https://github.com/temporalio/temporal/pull/11503", "createdAt": "2026-08-12T16:09:27Z", "updatedAt": "2026-08-12T16:39:56Z", "timestamp": "2026-08-12T16:39:56Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11505", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Track process-lifetime object leak baselines", "text": "## What changed? Add process-lifetime baselines to `objectleak`, ignore tiny pointer-free allocations that the runtime cannot track individually, and allow asynchronous cleanup the full settle timeout. ## Why? Make object leak reports actionable by distinguishing process-lifetime objects from leaks and avoiding runtime-induced false positives. Replaces #11313.", "url": "https://github.com/temporalio/temporal/pull/11505", "createdAt": "2026-08-12T16:47:47Z", "updatedAt": "2026-08-13T15:25:51Z", "timestamp": "2026-08-13T15:25:51Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11506", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Reuse one persistence factory during server initialization", "text": "## What changed? Reuse a single persistence factory during server initialization and expose it to the root Fx graph as `BootstrapPersistenceFactory`. The named interface encodes the startup-only lifecycle without tags, bridges, or adapters. The factory is closed exactly once after startup, on failed construction, or during `Stop` when the server was never started. Callers are now explicitly documented as responsible for calling `Stop`. Companion SaaS change: temporalio/saas-temporal#8369. ## Why? Server initialization previously constructed and closed a separate persistence factory for each bootstrap operation. One explicitly owned bootstrap factory avoids premature closes, makes cleanup deterministic, and helps #11458 by ensuring uninterrupted ownership of the SQLite database. ## Testing - `go test -count=1 ./temporal -run ^TestNewServer$` - `go test -count=1 -run ^$ ./temporal ./tests/testcore` - `go vet ./temporal ./tests/testcore` The full `./temporal` run reached the existing flaky `TestNewServerWithOTEL` span assertion; the targeted server lifecycle test passed.", "url": "https://github.com/temporalio/temporal/pull/11506", "createdAt": "2026-08-12T16:47:49Z", "updatedAt": "2026-08-12T19:56:04Z", "timestamp": "2026-08-12T19:56:04Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11507", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Close SQLite databases with their owners", "text": "## What changed? Properly close SQLite connections and databases. ## Why? SQLite previously retained one shared connection pool per DSN for the entire process. Each SQL factory now owns an initial reference while its stores borrow additional references. Closing the final factory releases the connection pool without losing an in-memory database when shorter-lived stores close. Replaces #11458.", "url": "https://github.com/temporalio/temporal/pull/11507", "createdAt": "2026-08-12T16:47:52Z", "updatedAt": "2026-08-12T16:47:52Z", "timestamp": "2026-08-12T16:47:52Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11508", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Eliminate expected object leak suppressions", "text": "## What changed? - Unregister process-global gRPC resolver and OpenTelemetry logger state during lifecycle shutdown. - Close the test matching client RPC factory and clear removed test references. - Remove every `WithExpected` entry from `objectLeakOpts`. ## Why? The leak test was suppressing the cluster graph instead of enforcing that cluster-owned objects become collectible. These lifecycle fixes leave only the protobuf traversal prune. ## Testing - `go test -count=1 -tags test_dep ./common/membership -run 'TestGRPCResolver'` - `go test -count=1 ./temporal` - `go test -count=1 ./tests/testcore -run 'TestSharedClusterT_RemoveTestReleasesTest'` - `go test -count=1 ./tests/leakcheck -run '^$'` Replaces #11503.", "url": "https://github.com/temporalio/temporal/pull/11508", "createdAt": "2026-08-12T16:47:54Z", "updatedAt": "2026-08-13T15:55:24Z", "timestamp": "2026-08-13T15:55:24Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11509", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "run admin batch in temporal-system", "text": "## What changed? 1. updated batch administration operations to run in the system namespace while continuing to use per-namespace task queues and workers. 2. allow batch activities running in the system namespace operating on other target namespaces 3. add ns to jobID and print all previous changes in tdbg prompts ## Why? to run refresh tasks in passive clusters of user global namespaces ## 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 refer to validation of the security for cross ns operation", "url": "https://github.com/temporalio/temporal/pull/11509", "createdAt": "2026-08-12T18:15:28Z", "updatedAt": "2026-08-12T18:16:06Z", "timestamp": "2026-08-12T18:16:06Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "feiyang3cat", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11510", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Reduce worker deployment log spam", "text": "Remove temporary worker deployment workflow logs to reduce log spam. Checks: `go test -tags test_dep ./service/worker/workerdeployment`; `make lint-code`. --- > [!NOTE] > **Low Risk** > Logging-only deletion with no control-flow or state changes in the deployment workflow. > > **Overview** > Removes temporary **Info**-level debug logging from the worker deployment workflow in `workflow.go` to cut log volume in steady state and during continue-as-new. > > Deleted log sites include workflow startup (raw state dump), run start, continue-as-new eligibility, the continue-as-new transition itself, **SetCurrent** update entry, and **updateMemo**—each previously tagged for removal. Workflow logic, metrics, and existing error/info paths are unchanged. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 17d70832a604132536bec962e4203cd6fc1d087f. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot). ", "url": "https://github.com/temporalio/temporal/pull/11510", "createdAt": "2026-08-12T19:28:00Z", "updatedAt": "2026-08-12T19:57:21Z", "timestamp": "2026-08-12T19:57:21Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "carlydf", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11511", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Preserve UTF-8 in test summaries", "text": "Test summary details are truncated to byte budgets before being written to Markdown and JSON. Ensure the retained head and tail start at UTF-8 rune boundaries so multibyte failure output remains valid after truncation. The regression test uses multibyte input whose previous tail boundary split a rune.", "url": "https://github.com/temporalio/temporal/pull/11511", "createdAt": "2026-08-12T21:57:45Z", "updatedAt": "2026-08-12T21:57:45Z", "timestamp": "2026-08-12T21:57:45Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11512", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Use generic JUnit documents at runner boundaries", "text": "Moves testrunner report inputs, outputs, and summaries onto the shared JUnit document types. The existing reporting behavior remains unchanged behind that seam. Stack: depends on #11513. Parser separation follows in #11487.", "url": "https://github.com/temporalio/temporal/pull/11512", "createdAt": "2026-08-12T22:00:08Z", "updatedAt": "2026-08-13T17:46:52Z", "timestamp": "2026-08-13T17:46:52Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11513", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Harden shared JUnit report IO", "text": "Strengthens shared JUnit reads and writes. Reads reject trailing XML and include the source path in errors. Writes validate counters and atomically replace the destination so interrupted writes cannot corrupt an existing report. This is the bottom of the testrunner reporting stack.", "url": "https://github.com/temporalio/temporal/pull/11513", "createdAt": "2026-08-12T22:05:45Z", "updatedAt": "2026-08-13T17:46:49Z", "timestamp": "2026-08-13T17:46:49Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11514", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Define canonical Go test attempt results", "text": "Defines the package-aware canonical attempt model and its queries for failed leaves, incomplete executions, package aborts, runtime failures, process failures, and retry safety. Tests construct results directly and pin these invariants before production uses the model. Stack: depends on #11487. Scoped canonical diagnostics follow in #11488.", "url": "https://github.com/temporalio/temporal/pull/11514", "createdAt": "2026-08-12T22:10:10Z", "updatedAt": "2026-08-13T17:47:01Z", "timestamp": "2026-08-13T17:47:01Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11515", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Record canonical Go test attempt results", "text": "Runs Go tests directly with JSON output and records package-aware canonical attempt results. The recorder owns event attribution, build failures, diagnostics, timeouts, console output, process state, and coverage-path handling, with focused unit and subprocess tests. Stack: depends on #11488. Retry policy follows in #11516.", "url": "https://github.com/temporalio/temporal/pull/11515", "createdAt": "2026-08-12T22:12:35Z", "updatedAt": "2026-08-13T17:47:08Z", "timestamp": "2026-08-13T17:47:08Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11516", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Plan test retries from canonical results", "text": "Moves retry selection, argument rewriting, and missing-rerun validation into a focused policy over canonical attempt results. The current runner still owns orchestration, so this PR changes the decision module without switching the reporting pipeline. Stack: depends on #11515. Canonical JUnit rendering follows in #11517.", "url": "https://github.com/temporalio/temporal/pull/11516", "createdAt": "2026-08-12T22:14:53Z", "updatedAt": "2026-08-13T17:47:12Z", "timestamp": "2026-08-13T17:47:12Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:temporalio/temporal:pull_request:11517", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Render JUnit from canonical attempt results", "text": "Adds the pure canonical attempt-history renderer, including parent-failure suppression, diagnostics, timeouts, aborts, build errors, retry suffixes, crash reports, exact counters, and numeric durations. Integration coverage verifies the persisted JUnit shape and the downstream sharding consumer. Stack: depends on #11516. The production cutover follows in #11518.", "url": "https://github.com/temporalio/temporal/pull/11517", "createdAt": "2026-08-12T22:18:31Z", "updatedAt": "2026-08-13T17:47:17Z", "timestamp": "2026-08-13T17:47:17Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:temporalio/temporal:pull_request:11518", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Adopt canonical test reporting pipeline", "text": "Switches orchestration to canonical attempt results and JUnit rendering, then removes the legacy JUnit merger and temporary diagnostic adapter in the same PR. Intermediate and final artifacts come from one attempt history, and report writes reject inconsistent counters. Stack: depends on #11517. Explicit orchestration outcomes follow in #11033.", "url": "https://github.com/temporalio/temporal/pull/11518", "createdAt": "2026-08-12T22:21:21Z", "updatedAt": "2026-08-13T17:47:21Z", "timestamp": "2026-08-13T17:47:21Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:temporalio/temporal:pull_request:11520", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Populate CallbackInfo.outcome", "text": "⚠️ This is part of a stacked PR set, to be merged into `chrsmith/wc-add-worker-cb-variant`. This will not go directly into `main`. This was originally sent out as https://github.com/temporalio/temporal/pull/11413, which also persisted the terminal failure of CHASM Callback components. This new version does not do that, and instead just includes the various refactorings and cleanups. --- ## What changed? The [worker callbacks API changes](https://github.com/temporalio/api/compare/feature/worker-callbacks?expand=1) adds the result of a Callback invocation to the `CallbackInfo` object. This PR wires it through for the Describe- response for Standalone Activities. (We already have tests that the completion callbacks were triggered for standalone activities, we now just verify the `CallbackInfo`'s returned have the right `outcome` data as well.) As part of this, various refactorings were applied to consolidate the conversion logic for `callback.Callback` and other types. (e.g. getting the API Status enum value, or the `commonpb.Callback` proto.) ## Why? This wiring and the associated refactorings are all part of adding worker callbacks, and making that easier to land. (Worker callbacks will need to wire the `CallbackInfo` objects to the Describe- endpoint, covered in a subsequent PR.) ## How did you test it? - [x] built - [x] run locally and tested manually - [x] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) ## Potential risks None that I can think of.", "url": "https://github.com/temporalio/temporal/pull/11520", "createdAt": "2026-08-12T22:33:50Z", "updatedAt": "2026-08-12T23:09:33Z", "timestamp": "2026-08-12T23:09:33Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "chrsmith", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11522", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add flaky test report input artifact", "text": "## What changed? - Add a fan-in job to the test workflow after unit, integration, and functional tests. - Download the current attempt's per-job JUnit artifacts and upload them as one `flaky-report-input----` artifact. - Include the fan-in job in the aggregate test status. This PR only produces the rollup artifact; it does not change the flaky-report consumer yet. ## Why? Give the flaky-test reporting workflow one artifact per CI run to download instead of discovering and downloading every job artifact independently. ## 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) Validated the workflow with Ruby's YAML parser and `git diff --check`. ## Potential risks The aggregate test status now fails if the fan-in job cannot find or upload JUnit reports. The rollup artifact retains the existing reports for 28 days, adding artifact storage until the consumer migrates.", "url": "https://github.com/temporalio/temporal/pull/11522", "createdAt": "2026-08-13T00:14:52Z", "updatedAt": "2026-08-13T00:32:59Z", "timestamp": "2026-08-13T00:32:59Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "chaptersix", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11523", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Use Go client for flaky report GitHub API calls", "text": "## What changed? - Replace the `gh api` subprocesses used by `flakereport` with a shared Go HTTP client. - Rate-limit GitHub API requests to 10 RPS by default; allow an explicit `--rps` override. - Stream artifact downloads to temporary files while preserving the existing 60-second download deadline and artifact worker pool. ## Why? The report performs a GitHub API request for every artifact. Avoiding a new `gh` process for each request removes that per-request overhead without adding a more complex processing pipeline. ## How did you test it? - [x] added new unit test(s) - [x] checked the diff for whitespace errors - [ ] built - [ ] run locally and tested manually - [ ] covered by existing tests - [ ] added new functional test(s) ## Potential risks The client uses the existing `GH_TOKEN`/`GITHUB_TOKEN` environment variables, falling back to one `gh auth token` call. Transient API errors are surfaced to the existing per-artifact error handling rather than retried.", "url": "https://github.com/temporalio/temporal/pull/11523", "createdAt": "2026-08-13T00:56:33Z", "updatedAt": "2026-08-13T02:35:47Z", "timestamp": "2026-08-13T02:35:47Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "chaptersix", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11524", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Index GitHub Actions runs for flake bisecting", "text": "## What changed? - Build one index from parsed test attempts keyed by normalized test name and GitHub Actions run commit. - Reuse that index when selecting and bisecting tests instead of rescanning every parsed attempt for each candidate. - Use `githubActions...` names in the bisect path to distinguish GitHub Actions runs from Temporal workflows. ## Why? A report can contain millions of parsed attempts. The previous bisect loop rescanned all of them for every candidate test. ## How did you test it? - [x] covered by existing tests - [x] checked the diff for whitespace errors - [ ] built - [ ] run locally and tested manually - [ ] added new unit test(s) - [ ] added new functional test(s) ## Potential risks This is stacked on #11523. The index preserves full test counts for qualification while excluding attempts without an in-range GitHub Actions commit from commit observations, matching the previous behavior.", "url": "https://github.com/temporalio/temporal/pull/11524", "createdAt": "2026-08-13T00:56:37Z", "updatedAt": "2026-08-13T02:35:47Z", "timestamp": "2026-08-13T02:35:47Z", "metrics": { "reactions": 1, "comments": 1 }, "labels": [], "author": "chaptersix", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11526", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Fix flakereport incomplete JUnit failures", "url": "https://github.com/temporalio/temporal/pull/11526", "createdAt": "2026-08-13T01:11:18Z", "updatedAt": "2026-08-13T14:53:28Z", "timestamp": "2026-08-13T14:53:28Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11527", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Fix sticky queue stats zeroed out", "text": "## What Skip the versioning attribution logic when computing stats for sticky queues. Otherwise, we end up with 0 value for add and dispatch rates. This breaks poller autoscaling for sticky queues: 0/0 = NaN, and NaN > threshold is always false, so no +1 scaling signals are ever emitted. Background DescribeTaskQueue returns stats like add_rate and dispatch_rate. For versioned task queues, these stats are obtained from the unversioned physical queue. So when we query the stats for the unversioned queue, we subtract the stats already attributed to the versioned queue. This way, we don't double count. Sticky queues on the other hand are not versioned; they only have the unversioned physical queue. So the above logic is not applicable. Since sticky queue inherits the user data from the normal queue, it was incorrectly treated as versioned. ## How did you test it? Unit tests 🤖 Generated with [Claude Code](https://claude.com/claude-code)", "url": "https://github.com/temporalio/temporal/pull/11527", "createdAt": "2026-08-13T01:42:36Z", "updatedAt": "2026-08-13T17:26:40Z", "timestamp": "2026-08-13T17:26:40Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "rkannan82", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11528", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Improve flaky report presentation", "text": "## What changed? - Shows Bayesian commit suspects directly below the overall stats. - Separates synthetic test-runner timeouts from test failures and reports affected artifacts. - Shows final-retry test failures as affected-artifact counts rather than workflow-run rates. ## Why? The synthetic `testrunner.TotalTimeout` event was reported both as a flaky test and as a CI breaker, while the former CI-breaker percentage mixed artifact and workflow-run units. ## How did you test it? - `go test -tags test_dep ./tools/flakereport ./tools/common/github` - `make lint-code` ## Potential risks This changes report categorization and presentation only; raw `failures.json` retains synthetic timeout records as timeout events.", "url": "https://github.com/temporalio/temporal/pull/11528", "createdAt": "2026-08-13T01:43:14Z", "updatedAt": "2026-08-13T02:52:39Z", "timestamp": "2026-08-13T02:52:39Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "chaptersix", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11529", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "JWT audience env config", "text": "## What changed? Added TEMPORAL_JWT_AUDIENCE to the embedded and Docker configuration templates, mapping the environment variable to global.authorization.audience. ## Why? JWT audience validation needs to be configurable in environment-based deployments, consistent with the existing JWT authorization settings. ## How did you test it? - [x] built - [ ] run locally and tested manually - [x] covered by existing tests - [ ] added new unit test(s) - [ ] added new functional test(s) ## Potential risks An incorrect TEMPORAL_JWT_AUDIENCE value can cause JWT-authenticated requests with a different audience to be rejected. When unset, it defaults to an empty value, preserving existing configuration behavior.", "url": "https://github.com/temporalio/temporal/pull/11529", "createdAt": "2026-08-13T05:08:07Z", "updatedAt": "2026-08-13T05:08:09Z", "timestamp": "2026-08-13T05:08:09Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "wtg-peternguyen", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11530", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Fix Schedule V2 BUFFER_ONE with a deferred start", "text": "## Summary - include an existing deferred BUFFER_ONE start in overlap resolution - prevent a later occurrence from becoming a second buffered start - add a focused regression test with one running, one deferred, and one new occurrence ## Production replay evidence The representative V1 history changed from 5,355 V1 actions versus 4,961 CHASM actions to 5,355 versus 5,355. Extra and missing workflow identities disappeared; only observation-time differences remain. ## Test plan - `go test -tags test_dep ./chasm/lib/scheduler -run \"^TestProcessBufferTask_BufferOne(KeepsExistingDeferredStart)?$\" -count=1` - representative three-history production replay", "url": "https://github.com/temporalio/temporal/pull/11530", "createdAt": "2026-08-13T06:14:42Z", "updatedAt": "2026-08-13T06:14:42Z", "timestamp": "2026-08-13T06:14:42Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "davidporter-id-au", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11531", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add Schedule V1 to V2 replay and detect coalesced updates", "text": "## Summary - add the offline Schedule V1 history to CHASM replay harness and production sampling tools - associate captured V1 starts with their workflow-task completion - detect an update signal delivered after workflow-task scheduling but before workflow-task start - classify input differences at this boundary as inconclusive rather than a significant V2 divergence - add sanitized workflow-history and controlled-corpus coverage ## Why V1 can consume a timer and update in one workflow task. An event-by-event harness may fire the nominal CHASM deadline before it encounters the update event, producing an old-input versus new-input false positive. ## Production replay evidence The representative request-input case moves from significant to inconclusive with the causal name `v1_workflow_task_input_ordering`. ## Test plan - `go test -tags test_dep ./chasm/lib/scheduler -run \"^(TestWorkflowTaskContainsUpdateBeforeStart|TestDownloadedV1HistoriesAgainstCHASM)$\" -count=1` - representative three-history production replay", "url": "https://github.com/temporalio/temporal/pull/11531", "createdAt": "2026-08-13T06:14:47Z", "updatedAt": "2026-08-13T06:18:20Z", "timestamp": "2026-08-13T06:18:20Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "davidporter-id-au", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11532", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Reproduce migrated zero catchup compatibility gap", "text": "## Summary - characterize V1 resolution of an explicit zero catchup window to the 10-second minimum - prove migration currently preserves the explicit zero value - pair these tests with existing CHASM coverage where zero resolves to the one-year default ## Finding This is a genuine migration compatibility difference. In the representative history, all 15 CHASM-only actions were decided 10 to 112 seconds after nominal time. V1 dropped them under its 10-second window while CHASM retained them under its default window. This draft intentionally does not choose a fix. A migration-only compatibility rule may be appropriate; globally changing V2 would alter its intended zero-means-unset behavior. ## Test plan - `go test -tags test_dep ./service/worker/scheduler -run \"^TestWorkflow/TestZeroCatchupWindowUsesMinimum$\" -count=1` - `go test -tags test_dep ./chasm/lib/scheduler/migration -run \"^TestLegacyToCreateFromMigrationStateRequest_PreservesZeroCatchupWindow$\" -count=1` - existing CHASM non-positive catchup tests - representative three-history production replay", "url": "https://github.com/temporalio/temporal/pull/11532", "createdAt": "2026-08-13T06:14:55Z", "updatedAt": "2026-08-13T06:14:55Z", "timestamp": "2026-08-13T06:14:55Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "davidporter-id-au", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11533", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Update test shard salt", "text": "Automatically generated by the optimize-test-sharding workflow.", "url": "https://github.com/temporalio/temporal/pull/11533", "createdAt": "2026-08-13T07:33:14Z", "updatedAt": "2026-08-13T15:03:18Z", "timestamp": "2026-08-13T15:03:18Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "temporal-cicd[bot]", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11535", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Update Selected API list.", "text": "## What changed? Added more state-effecting API calls to the forwarding list. ## Why? The intent is for passive to always forward those APIs it cannot handle locally. ## How did you test it? - [x] built - [ ] run locally and tested manually - [x] covered by existing tests - [ ] added new unit test(s) - [ ] added new functional test(s) --- > [!NOTE] > **Medium Risk** > Changes which cross-cluster RPCs are auto-forwarded for global namespaces; misconfiguration could leave state changes on passive clusters or alter failover behavior for new API types. > > **Overview** > Expands **selected-apis-forwarding** so passive clusters forward additional **state-effecting** RPCs to the namespace’s active cluster. > > **Workflow APIs** newly whitelisted: `UpdateWorkflowExecution`, `PauseWorkflowExecution`, `UnpauseWorkflowExecution`, `ResetWorkflowExecution`, and `ExecuteMultiOperation`. Policy comments now describe forwarding as state-effecting APIs and point readers at `selectedAPIsForwardingRedirectionPolicyWhitelistedAPIs` instead of an inline list. > > Tests add **`TestSelectedAPIs`** to assert the full whitelist (workflow, standalone activity, and Nexus operation APIs). The non-whitelisted API case is fixed by suffixing API names with `_notwhitelisted` and using a global namespace whose active cluster is remote, so forwarding tests no longer accidentally exercise whitelisted names. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 07fed6a663b2075bbf4a241043dbda346847d619. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot). ", "url": "https://github.com/temporalio/temporal/pull/11535", "createdAt": "2026-08-13T11:31:39Z", "updatedAt": "2026-08-13T16:22:10Z", "timestamp": "2026-08-13T16:22:10Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation" ], "author": "robholland", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11536", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Validate fairsim inputs and preserve counter defaults", "text": "## What changed? - Decode partial counter parameter JSON over `counter.DefaultCounterParams`. - Return a validation error when `-partitions` is zero or negative. - Add regression tests for partial counter overrides and invalid partition counts. ## Why? The README documents partial overrides such as `{\"CMS\":{\"W\":100}}`, but the simulator decoded them into a zero-valued struct. Omitted fields including `MapLimit` were reset to zero, and the documented command could panic when adding its first task. Non-positive partition counts similarly reached `rand.IntN` and panicked. Loading partial overrides over the production defaults makes the documented parameter-sweep workflow behave as intended. Validating the partition count keeps invalid CLI input on the normal error path. Fixes #11534 ## How did you test it? - [x] built - [x] run locally and tested manually - [x] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) Ran: ```bash go test -tags test_dep ./tools/fairsim ./service/matching/counter make lint-code ``` Also ran the README-style partial override against the rebuilt binary and confirmed that unspecified fields retain their defaults. ## Potential risks This changes only the simulator CLI. Explicit values in the JSON, including zero values, still override defaults.", "url": "https://github.com/temporalio/temporal/pull/11536", "createdAt": "2026-08-13T11:34:50Z", "updatedAt": "2026-08-13T12:32:29Z", "timestamp": "2026-08-13T12:32:29Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "Aminkbi", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11537", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Clamp matching read partition count", "text": "## What changed? Clamp the dynamic-config fallback for matching read partition count to at least one, and cover zero and negative configured values with unit tests. ## Why? Before a matching client has cached server-provided partition counts, `PickReadPartition` falls back to `matching.numTaskqueueReadPartitions`. A non-positive configured value reaches `math/rand.Intn(0)` and panics while routing a worker poll. Request handlers recover the panic as an internal error, so affected workers cannot receive tasks and each poll logs a panic until the configuration or cache state changes. The write path already clamps the same dynamic configuration fallback to one. The matching task-queue configuration also exposes read and write counts with this lower bound. Applying the same guard in the client read path makes the behavior consistent. ## How did you test it? - [x] built - [ ] run locally and tested manually - [x] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) Ran: ```bash go test -tags test_dep ./client/matching -count=1 go test -race -tags test_dep ./client/matching -run \"^TestPickReadPartition_NonPositiveConfiguredCount$\" -count=1 make lint-code ``` The regression test reproduced the pre-fix panic for both zero and negative configured counts. ## Potential risks For invalid non-positive configuration, polls now route to the root partition instead of returning an internal error from a recovered panic. Positive configuration and server-provided partition counts are unchanged.", "url": "https://github.com/temporalio/temporal/pull/11537", "createdAt": "2026-08-13T11:35:20Z", "updatedAt": "2026-08-13T12:33:33Z", "timestamp": "2026-08-13T12:33:33Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "Aminkbi", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11538", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "1.32.0: Prepare release branch", "text": "Prepare release branch: - Overwrite governance files - Update dependencies", "url": "https://github.com/temporalio/temporal/pull/11538", "createdAt": "2026-08-13T11:39:25Z", "updatedAt": "2026-08-13T11:39:37Z", "timestamp": "2026-08-13T11:39:37Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "temporal-cicd[bot]", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11541", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Attribute queue reader stuck attempts to a slice", "text": "## What changed? - count reader stuck attempts per slice and per owning reader instead of per wall clock second (`SetReaderWatermark` -> `SetSliceReadWatermark`) - report each stuck window once, and only when the alert was actually queued - track read progress for every reader rather than only the default one, and stop creating readers at `MaxReaderCount` - only split slices that genuinely overlap the stuck range, via a new `Range.CanSplitStrictly` ## Why? The attempt counter was keyed on the truncated fire time of the last loaded task. A shard that keeps generating tasks gets a new slice per notification and several of them can land in the same second, so every read made progress in its own slice while the shared counter still climbed — the policy fired on healthy shards. That is why `history.queueReaderStuckCriticalAttempts` is currently raised high enough to disable it in practice. Attributing attempts to a slice only counts repeated reads that fail to move past one fire time window *within a single slice*, which is the condition worth splitting out, and it needs no extra time threshold to tell the two apart. Progress is also keyed on the owning reader, so a slice moved whole to the next reader is judged on that reader's own reads instead of being demoted again on its first one. `Range.CanSplit` is inclusive at both bounds, so slices merely adjacent to the stuck window were split into empty pieces and merged into the next reader, creating that reader for nothing. ## How did you test it? - [x] built - [x] covered by existing tests - [x] added new unit test(s) `action_reader_stuck.go` had no test file before. The new table test covers every overlap shape, the reader count bound, and the merge into an existing next reader. Each fix was confirmed to fail against the pre-fix logic, including that the reader attributes progress to the slice and reader it actually read with. ## Potential risks Reader stuck is effectively disabled by config today, so this only changes production behaviour once `queueReaderStuckCriticalAttempts` is lowered again. Tracking non-default readers means the last reader can now alert for a window nothing can be done about, since there is no lower priority reader to move it to. The report-once latch bounds that to one alert per slice and window, but each one still costs a checkpoint. Known limitation worth a decision before the config is lowered: slice identity is not stable. `processNewRange` merges each new range into the reader's slices, and `MergeWithSlice` destroys and rebuilds them, so the attempt count restarts. That can only delay detection, never cause a false positive, but on a shard that keeps generating timers the merge cadence can outrun `ReaderStuckCriticalAttempts` reads and hold detection off. Carrying progress across split/merge, or keying it on `(readerID, watermark, Range.InclusiveMin)` which survives a merge, would close the gap — both need their own eviction story, so they are left out here.", "url": "https://github.com/temporalio/temporal/pull/11541", "createdAt": "2026-08-13T15:41:46Z", "updatedAt": "2026-08-13T16:43:30Z", "timestamp": "2026-08-13T16:43:30Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "prathyushpv", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11542", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Release removed shared cluster test references", "text": "## What changed? Clear removed tests from the shared cluster's backing slice. ## Why? `sharedClusterT` shortened `activeTests` without clearing the removed interface slot. The backing array could therefore retain completed tests and their functional test state.", "url": "https://github.com/temporalio/temporal/pull/11542", "createdAt": "2026-08-13T15:47:53Z", "updatedAt": "2026-08-13T16:12:39Z", "timestamp": "2026-08-13T16:12:39Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11543", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Release gRPC resolver registrations on shutdown", "text": "## What changed? Tie process-global gRPC resolver registrations to their Fx and test owners. Resolver URLs use monotonic opaque registration IDs, test callers register cleanup directly, and matching test clients close their RPC factories during cluster shutdown. The leak test drops the corresponding host expectation. ## Why? The process-global resolver map retained cluster-owned state after shutdown. Explicit cleanup releases those references while preserving resolver availability during Fx graph construction. ## Testing - `go test -race -tags disable_grpc_modules,test_dep ./common/membership ./common/rpc/test ./tests/testcore -count=1` - `LEAK_ITERS=5 LEAK_ITERS_WARMUP=1 LEAK_GC_SETTLE_TIMEOUT=30s go test -run TestClusterShutdownLeak -count=1 -timeout 6m -tags disable_grpc_modules,,test_dep, ./tests/leakcheck/ -args -persistenceType=sql -persistenceDriver=sqlite` Stacked on #11542.", "url": "https://github.com/temporalio/temporal/pull/11543", "createdAt": "2026-08-13T15:50:19Z", "updatedAt": "2026-08-13T18:01:05Z", "timestamp": "2026-08-13T18:01:05Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "request-claude-review" ], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" }, { "id": "github:temporalio/temporal:pull_request:11544", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Enforce zero expected object leaks", "text": "## What changed? Remove the final `FunctionalTestBase.testCluster.testBase*` expectation. `objectLeakOpts` now contains only the protobuf traversal prune and no expected leaks. ## Why? The preceding stack releases shared-test and process-global references. Together with the persistence ownership fixes in #11506 and #11507, functional test clusters become fully collectible. ## Testing - `go test -count=1 ./tests/leakcheck -run '^$'` - With #11506 and #11507 applied: `make LEAK_ITERS=5 LEAK_ITERS_WARMUP=2 LEAK_GC_SETTLE_TIMEOUT=10s LEAK_TIMEOUT=3m leak-test` Stacked on #11543. Also depends on #11506 and #11507.", "url": "https://github.com/temporalio/temporal/pull/11544", "createdAt": "2026-08-13T15:51:29Z", "updatedAt": "2026-08-13T17:01:38Z", "timestamp": "2026-08-13T17:01:38Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "stephanos", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11546", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "fix(batcher): scope deterministic request IDs to the batch job ID", "text": "## What changed? Use the `jobID` parameter in the `deterministicRequestID` function to allow multiple batch operations to signal the same workflow. ## Why? Two batch operations that send the same signal to the same workflow/run ID will only send one signal, the second will be de-duped in the signal logic because the request ID was hashed from workflow id / run id / signal name. Including the batch job ID gives proper hashing to prevent these separate signals from being de-duped ## How did you test it? - [x] added new unit test(s) - [x] added new functional test(s) ## Potential risks NA, this is a bug fix.", "url": "https://github.com/temporalio/temporal/pull/11546", "createdAt": "2026-08-13T16:13:40Z", "updatedAt": "2026-08-13T17:38:09Z", "timestamp": "2026-08-13T17:38:09Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "reliability-2026" ], "author": "spkane31", "state": "closed", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11548", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "fix time-skipping flaky tests", "text": "## What changed? fix the flaky test of time skipping`CanceledTimerNotUsedAsSkipTarget`", "url": "https://github.com/temporalio/temporal/pull/11548", "createdAt": "2026-08-13T16:34:53Z", "updatedAt": "2026-08-13T17:11:56Z", "timestamp": "2026-08-13T17:11:56Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "feiyang3cat", "state": "open", "assignees": [] }, { "id": "github:temporalio/temporal:pull_request:11551", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Release OTEL logger registrations on shutdown", "text": "## What changed? Route process-global OTEL errors through lifecycle-owned logger registrations. The handler selects the newest ready registration and drops each logger reference when its Fx owner stops. The leak test drops the corresponding logger expectation. ## Why? The process-global OTEL error handler retained the server logger after shutdown. Lifecycle ownership releases that reference while supporting multiple in-process servers. ## Testing - `go test -race -tags disable_grpc_modules,test_dep ./temporal -count=1` - `LEAK_ITERS=5 LEAK_ITERS_WARMUP=1 LEAK_GC_SETTLE_TIMEOUT=30s go test -run TestClusterShutdownLeak -count=1 -timeout 6m -tags disable_grpc_modules,,test_dep, ./tests/leakcheck/ -args -persistenceType=sql -persistenceDriver=sqlite` Based on #11542.", "url": "https://github.com/temporalio/temporal/pull/11551", "createdAt": "2026-08-13T17:59:38Z", "updatedAt": "2026-08-13T17:59:38Z", "timestamp": "2026-08-13T17:59:38Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "new" } ], "events": [ { "id": "event:539255a2e472b6874529", "signalId": "github:temporalio/temporal:pull_request:11303", "event": "discovered", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11303", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add replication stream lane wire protocol and receiver-side lane routing", "text": "> **Part 3 of a 5-PR series** building to replication stream namespace isolation (a restructuring of #10147): read buffer → reader group → lane protocol → isolation manager → sender isolation. > #11302 (reader group) has merged, so this PR's diff is now standalone against `main`. · **Next in series: #11304** (isolation manager). ## What changed? The wire-level building blocks for per-namespace lane isolation, receiver side only: - **Proto**: `SyncReplicationState` gains `pause_high_namespace_ids` (namespaces the receiver reports as overwhelming the HIGH lane — the priority lives in the field name, so a future LOW extension adds its own field rather than widening this one), `isolated_lane_states` (per-lane applied watermarks keyed by namespace ID — with the documented caveat that a missing key is ambiguous between \"not tracked yet\" and \"retired and drained\", so a sender must never treat absence alone as drain proof), and `supports_namespace_isolation` (capability advertisement, so a sender never emits lane-tagged traffic to a receiver that would misroute it). `WorkflowReplicationMessages` gains `isolated_namespace_id` — when set, the batch belongs to that namespace's dedicated lane — and `retire_isolated_lane`, marking a lane's final message. - **Receiver**: lane-tagged batches route to lazily-created per-namespace task trackers. Each lane is its own monotonic stream for the life of the connection — there is no rewind or rotation machinery, because the sender-side design (later in the series) gives every lane a single owner cursor that never goes backwards. Member-lane watermarks fold into the overall ack minimum (cleanup safety) and are reported per lane; member-lane backlogs count toward HIGH flow control. Lane lifecycle is defensive about ordering: a batch's tasks are tracked BEFORE its retire flag is applied (so the concurrent ack loop can never delete a lane whose final batch is mid-track), a retiring lane is only dropped once it is drained AND has tracked at least one batch, and non-retire traffic arriving on a retiring lane revives it (the sender re-isolated the namespace before the lane drained). Lane-tagged traffic at any priority other than HIGH is a protocol violation and fails the stream rather than silently mis-acking (isolation splits the HIGH lane only). Lanes created concurrently with `Stop()` are pre-cancelled so no tasks run after shutdown. - **`NamespaceThrottler`** interface (default: noop, via fx) observes per-namespace HIGH-priority task load and decides which namespaces to report. The sender does not tag lanes yet, so this is inert until the sender-side isolation lands. ## Why? Isolation needs a wire contract before the sender can use it: capability advertisement, per-lane routing and progress reporting, and the throttled-namespace feedback channel. Landing the receiver first makes mixed-version clusters safe by construction. Compared to #10147, lanes are per-namespace rather than shared per severity tier — which is what eliminates that design's cursor rewinds and the watermark-regression/tracker-rotation protocol this PR previously needed to compensate for them. ## How did you test it? - [x] built - [x] covered by existing tests - [x] added new unit test(s) — lane routing (priority routing when unset, per-namespace tracker identity, non-HIGH rejection), retirement lifecycle (drop once drained, never-tracked retiring lane survives the ack snapshot, revive on re-isolation traffic, fresh lane after drop), and post-Stop lane creation being pre-cancelled - [x] added new functional test(s) — exercised end-to-end by the xdc test in the final PR of the series ## Potential risks Inert until a sender emits `isolated_namespace_id`, which is gated behind both a config flag and the capability advertisement. Receiver-side lane state is bounded by the sender's isolation cap (final PR). 🤖 Generated with [Claude Code](https://claude.com/claude-code)", "url": "https://github.com/temporalio/temporal/pull/11303", "createdAt": "2026-07-27T12:22:32Z", "updatedAt": "2026-08-13T12:52:24Z", "timestamp": "2026-08-13T12:52:24Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation" ], "author": "robholland", "state": "open", "assignees": [], "change": "new" } }, { "id": "event:7fe42bff2fcb10dd1bf1", "signalId": "github:temporalio/temporal:pull_request:11537", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11537", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Clamp matching read partition count", "text": "## What changed? Clamp the dynamic-config fallback for matching read partition count to at least one, and cover zero and negative configured values with unit tests. ## Why? Before a matching client has cached server-provided partition counts, `PickReadPartition` falls back to `matching.numTaskqueueReadPartitions`. A non-positive configured value reaches `math/rand.Intn(0)` and panics while routing a worker poll. Request handlers recover the panic as an internal error, so affected workers cannot receive tasks and each poll logs a panic until the configuration or cache state changes. The write path already clamps the same dynamic configuration fallback to one. The matching task-queue configuration also exposes read and write counts with this lower bound. Applying the same guard in the client read path makes the behavior consistent. ## How did you test it? - [x] built - [ ] run locally and tested manually - [x] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) Ran: ```bash go test -tags test_dep ./client/matching -count=1 go test -race -tags test_dep ./client/matching -run \"^TestPickReadPartition_NonPositiveConfiguredCount$\" -count=1 make lint-code ``` The regression test reproduced the pre-fix panic for both zero and negative configured counts. ## Potential risks For invalid non-positive configuration, polls now route to the root partition instead of returning an internal error from a recovered panic. Positive configuration and server-provided partition counts are unchanged.", "url": "https://github.com/temporalio/temporal/pull/11537", "createdAt": "2026-08-13T11:35:20Z", "updatedAt": "2026-08-13T12:33:33Z", "timestamp": "2026-08-13T12:33:33Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "Aminkbi", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:dbc67f20e687316c2448", "signalId": "github:temporalio/temporal:issue:11539", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:issue:11539", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "DeleteWorkerDeploymentVersion fails permanently when a version summary outlives its version workflow", "text": "### What are you really trying to do? Keep the number of Worker Deployment Versions per deployment under `matching.maxVersionsInDeployment` by periodically deleting drained versions, so that new versions can always register. ### Describe the bug A Worker Deployment can end up listing a version in `DescribeWorkerDeployment`'s `versionSummaries` **after that version's own entity/workflow no longer exists**. Once in that state the entry is **permanently undeletable**: `DeleteWorkerDeploymentVersion` runs against a version workflow that isn't there and fails on every attempt, forever. The entry keeps counting toward `maxVersionsInDeployment`, and any automated cleanup that walks `versionSummaries` and deletes drained versions fails on it indefinitely. Observed on **server 1.30.3** (CLI 1.6.x), Postgres persistence, one namespace with 30d retention. The three views disagree with each other for the same build ID (names below are anonymized; `worker-a` is a deployment with 1 current + 21 drained versions, `1.42.0-a1b2` is the oldest drained one, created ~24 days earlier): ``` $ temporal worker deployment describe --name default/worker-a -o json -> versionSummaries contains build ID 1.42.0-a1b2, drainageStatus \"drained\" $ temporal worker deployment describe-version \\ --deployment-name default/worker-a --build-id 1.42.0-a1b2 ERROR error describing worker deployment version: build ID '1.42.0-a1b2' not found in Worker Deployment 'default/worker-a' $ temporal workflow describe \\ --workflow-id temporal-sys-worker-deployment-version:default/worker-a/1.42.0-a1b2 ERROR failed describing workflow: workflow not found for ID: ... ``` So the deployment workflow's version list and the version entities have diverged. Deleting it fails deterministically: ``` $ temporal worker deployment delete-version \\ --deployment-name default/worker-a --build-id 1.42.0-a1b2 --identity ERROR error deleting worker deployment version: something went wrong, please retry (36634b00) ``` The retry hint is misleading — it is not transient. Every invocation over ~2 days failed identically. ### Root cause as far as we could trace it The generic frontend error hides the real failure. The frontend logs only the wrapper: ``` {\"level\":\"error\",\"msg\":\"deployment client unexpected error\",\"error\":\"activity error\", \"operation\":\"DeleteWorkerDeploymentVersion\",\"deployment\":\"default/worker-a\", \"args\":[\"default\",\"1.42.0-a1b2\"], \"logging-call-at\":\"service/worker/workerdeployment/client.go:1266\"} ``` The actual cause appears only in the **system worker** logs: ``` {\"level\":\"error\",\"msg\":\"Activity error.\", \"Namespace\":\"default\",\"TaskQueue\":\"temporal-sys-per-ns-tq\", \"WorkflowID\":\"temporal-sys-worker-deployment:default/worker-a\", \"ActivityType\":\"DeleteWorkerDeploymentVersion\",\"Attempt\":1, \"Error\":\"workflow execution already completed\"} ``` i.e. the deployment workflow's `DeleteWorkerDeploymentVersion` activity targets the version workflow, finds it already completed/absent, and surfaces that as a non-actionable internal error instead of treating the desired end state (version gone) as satisfied. ### Suspected trigger Not conclusively established, so treat this as a hypothesis: the version workflow closed when the version drained and was then removed by **namespace retention** (30d here), while the deployment workflow — which continues-as-new and carries its version list forward — kept the summary entry. The affected version was the oldest in the deployment, consistent with it being the first to cross the retention boundary. If that is the mechanism, any long-lived deployment should accumulate these as versions age past retention. ### Minimal repro We do not have a clean synthetic repro, which is why the mechanism above is a hypothesis. It appeared naturally on a deployment with steady rollout churn. If retention is the trigger, the shape would be: register a version, make it current, supersede it so it drains, then let the version workflow age past the namespace retention, and attempt `delete-version` on it. ### Expected behaviour Any one of these would resolve it: 1. **`DeleteWorkerDeploymentVersion` is idempotent** — if the version workflow is already absent, remove the summary entry and return success rather than an internal error. This seems like the natural fix: the caller's intent is already satisfied. 2. **The deployment workflow prunes summaries** whose version entity no longer exists (e.g. on continue-as-new, or when a delete discovers the entity is missing). 3. Failing either, a **supported way to remove such an entry**. The only lever we can see is terminating `temporal-sys-worker-deployment:default/` so the list is rebuilt, which is not viable in production because that workflow holds live routing config (current/ramping version). Separately, and independent of the fix: **`something went wrong, please retry ()` for a permanent, non-retryable condition is hard to diagnose.** Propagating the activity's cause (or at least a distinct error type) to the caller would have saved most of this investigation. ### Impact Low severity but permanent and self-accumulating: - The stale entry consumes one slot against `maxVersionsInDeployment` (200 in our config) and can never be reclaimed. - Automated below-cap cleanup fails on it on every run. Ours ran every 6h and exited non-zero each time until we special-cased it: on a failed delete we now probe `describe-version` and, only if it reports the version as absent, count it as already-gone instead of a failure. That works, but it is a workaround for a state the server arguably shouldn't expose. ### Related Cross-referencing #10737, which covers version GC not reclaiming eligible drained versions at the cap. This looks like a distinct, second-order problem in the same area: there the versions *aren't* reclaimed, here a version *cannot* be reclaimed because the summary outlived the entity. ### Environment - Temporal Server: 1.30.3 (Helm, Postgres persistence, ES/advanced visibility not in use) - Temporal CLI: 1.6.x - Worker Deployment Versioning with an external controller managing rollouts; workflows are pinned by default - Relevant config: `matching.maxVersionsInDeployment: 200`; namespace retention 30d; `worker.buildIdScavengerEnabled: true`", "url": "https://github.com/temporalio/temporal/issues/11539", "createdAt": "2026-08-13T12:11:00Z", "updatedAt": "2026-08-13T12:11:00Z", "timestamp": "2026-08-13T12:11:00Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "noamyehudai", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:e55371a6a7736ddd9a7b", "signalId": "github:temporalio/temporal:pull_request:11538", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11538", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "1.32.0: Prepare release branch", "text": "Prepare release branch: - Overwrite governance files - Update dependencies", "url": "https://github.com/temporalio/temporal/pull/11538", "createdAt": "2026-08-13T11:39:25Z", "updatedAt": "2026-08-13T11:39:37Z", "timestamp": "2026-08-13T11:39:37Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "temporal-cicd[bot]", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:0c7f38601255eddb065f", "signalId": "github:temporalio/temporal:issue:11534", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:issue:11534", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "Fairsim partial counter configuration resets unspecified defaults", "text": "## Expected Behavior The partial counter configuration documented in `tools/fairsim/README.md` should override only the supplied values. For example: ```bash ./fairsim \\ -counter-params=<(echo '{\"CMS\":{\"W\":100}}') \\ -- -tasks=1000 -keys=500 ``` should set the CMS width to `100` while retaining all other values from `counter.DefaultCounterParams`. ## Actual Behavior `fairsim` unmarshals the JSON into a zero-valued `counter.CounterParams`. Omitted values such as `MapLimit`, CMS depth, growth settings, and reseeding interval therefore become zero. The loaded configuration includes: ```text MapLimit: 0 CMS.W: 100 CMS.D: 0 CMS.Grow: zero values CMS.Reseed.Interval: 0 ``` With `MapLimit` set to zero, processing the first task can panic in `mapCounter.updateHeap`. It also means that changing one CMS setting unintentionally changes the rest of the simulated counter configuration. ## Steps to Reproduce the Problem 1. Build `fairsim` from an unmodified checkout: ```bash make fairsim ``` 2. Run the partial configuration example: ```bash ./fairsim \\ -counter-params=<(echo '{\"CMS\":{\"W\":100}}') \\ -- -tasks=1000 -keys=500 ``` 3. Observe that unspecified counter parameters are zero instead of retaining their defaults, potentially followed by an index-out-of-range panic. ## Proposed Resolution Initialize the configuration with `counter.DefaultCounterParams` before unmarshalling the supplied JSON. This makes partial configuration files behave as documented while continuing to support explicit zero values. A regression test can load `{\"CMS\":{\"W\":10}}` and verify that only `CMS.W` changes while all other fields remain equal to `counter.DefaultCounterParams`. ## Specifications - Version: `main` at `632d694e7` - Platform: Linux amd64", "url": "https://github.com/temporalio/temporal/issues/11534", "createdAt": "2026-08-13T10:56:52Z", "updatedAt": "2026-08-13T11:35:38Z", "timestamp": "2026-08-13T11:35:38Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "Aminkbi", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:c2af62c242230dbf31dd", "signalId": "github:temporalio/temporal:pull_request:11536", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11536", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Validate fairsim inputs and preserve counter defaults", "text": "## What changed? - Decode partial counter parameter JSON over `counter.DefaultCounterParams`. - Return a validation error when `-partitions` is zero or negative. - Add regression tests for partial counter overrides and invalid partition counts. ## Why? The README documents partial overrides such as `{\"CMS\":{\"W\":100}}`, but the simulator decoded them into a zero-valued struct. Omitted fields including `MapLimit` were reset to zero, and the documented command could panic when adding its first task. Non-positive partition counts similarly reached `rand.IntN` and panicked. Loading partial overrides over the production defaults makes the documented parameter-sweep workflow behave as intended. Validating the partition count keeps invalid CLI input on the normal error path. Fixes #11534 ## How did you test it? - [x] built - [x] run locally and tested manually - [x] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) Ran: ```bash go test -tags test_dep ./tools/fairsim ./service/matching/counter make lint-code ``` Also ran the README-style partial override against the rebuilt binary and confirmed that unspecified fields retain their defaults. ## Potential risks This changes only the simulator CLI. Explicit values in the JSON, including zero values, still override defaults.", "url": "https://github.com/temporalio/temporal/pull/11536", "createdAt": "2026-08-13T11:34:50Z", "updatedAt": "2026-08-13T12:32:29Z", "timestamp": "2026-08-13T12:32:29Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "Aminkbi", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:e0563ea77562e42aae27", "signalId": "github:temporalio/temporal:pull_request:11535", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11535", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Update Selected API list.", "text": "## What changed? Added more state-effecting API calls to the forwarding list. ## Why? The intent is for passive to always forward those APIs it cannot handle locally. ## How did you test it? - [x] built - [ ] run locally and tested manually - [x] covered by existing tests - [ ] added new unit test(s) - [ ] added new functional test(s) --- > [!NOTE] > **Medium Risk** > Changes which global-namespace RPCs are auto-forwarded across clusters; incorrect routing could affect multi-DC control operations, though behavior follows the existing whitelist pattern with updated unit tests. > > **Overview** > Expands **selected-apis-forwarding** so more **state-effecting** workflow RPCs on passive clusters are routed to the namespace’s active cluster. > > The whitelist in `selectedAPIsForwardingRedirectionPolicyWhitelistedAPIs` now includes `UpdateWorkflowExecution`, pause/unpause/reset workflow, and `ExecuteMultiOperation`. Policy comments now point at that map instead of an inline API list. > > Tests add `TestSelectedAPIs` to lock the full whitelist (workflow, standalone activity, and Nexus operation APIs). The non-whitelisted API case is fixed by using suffixed API names and a setup where the active cluster is remote, so only non-listed RPCs are asserted to stay local. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit e065106ed0518e0df2f2f2b9a07464d603ce3f81. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot). ", "url": "https://github.com/temporalio/temporal/pull/11535", "createdAt": "2026-08-13T11:31:39Z", "updatedAt": "2026-08-13T11:31:57Z", "timestamp": "2026-08-13T11:31:57Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation" ], "author": "robholland", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:bfffc3266304e996e7fc", "signalId": "github:temporalio/temporal:pull_request:11033", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11033", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Return test runner orchestration outcomes", "text": "Makes test execution return an exit code and error instead of terminating inside the orchestration loop. This lets final artifact failures, retry-validation failures, execution errors, timeouts, and normal pass/fail outcomes be tested directly while `Main` remains the only process-exit boundary. Stack: depends on #11518 and completes the canonical `go test -json` reporting pipeline.", "url": "https://github.com/temporalio/temporal/pull/11033", "createdAt": "2026-07-13T19:38:51Z", "updatedAt": "2026-08-13T10:11:48Z", "timestamp": "2026-08-13T10:11:48Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "test-all-dbs", "request-claude-review" ], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:d5b64eaed846da4e5a32", "signalId": "github:temporalio/temporal:pull_request:11518", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11518", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Return report persistence errors", "text": "Makes crash and attempt-history persistence return errors to their callers. Intermediate writes remain best effort, final writes remain mandatory, and a focused test covers crash-report write failure without changing runner exit behavior yet. Stack: depends on #11517. Fallible runner orchestration follows this one.", "url": "https://github.com/temporalio/temporal/pull/11518", "createdAt": "2026-08-12T22:21:21Z", "updatedAt": "2026-08-13T10:11:43Z", "timestamp": "2026-08-13T10:11:43Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:13ced380260694fc9fcf", "signalId": "github:temporalio/temporal:pull_request:11517", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11517", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Simplify test runner attempt state", "text": "Removes the temporary runner-level `attempt` wrapper now that execution facts live in `attemptResult`. The runner stores result history directly and computes per-attempt coverage paths without changing retry, persistence, or exit behavior. Stack: depends on #11516. Fallible runner orchestration follows this one.", "url": "https://github.com/temporalio/temporal/pull/11517", "createdAt": "2026-08-12T22:18:31Z", "updatedAt": "2026-08-13T10:11:39Z", "timestamp": "2026-08-13T10:11:39Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:1e0ee3929e17f8d5332f", "signalId": "github:temporalio/temporal:pull_request:11516", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11516", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Remove legacy JUnit report merger", "text": "Deletes the now-unused legacy JUnit wrapper, synthetic-report builder, retry merger, and tree helper. Tests consume shared `Testsuites` documents directly, and summary fixtures explicitly model the already-canonical failure details they exercise. Stack: depends on #11515. Runner orchestration follows this one.", "url": "https://github.com/temporalio/temporal/pull/11516", "createdAt": "2026-08-12T22:14:53Z", "updatedAt": "2026-08-13T10:11:34Z", "timestamp": "2026-08-13T10:11:34Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:6d522e14be405d11508a", "signalId": "github:temporalio/temporal:pull_request:11515", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11515", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Persist canonical test attempt history", "text": "Persists completed attempt history directly through the canonical JUnit renderer for both intermediate and final reports. The testrunner write boundary now rejects inconsistent counters, while the legacy merger remains present but unused so its deletion can be reviewed separately. Stack: depends on #11488. Legacy JUnit cleanup follows this one.", "url": "https://github.com/temporalio/temporal/pull/11515", "createdAt": "2026-08-12T22:12:35Z", "updatedAt": "2026-08-13T09:54:10Z", "timestamp": "2026-08-13T09:54:10Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:9924c16638e60d330d8f", "signalId": "github:temporalio/temporal:issue:9522", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:issue:9522", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "Unable to create visibility database schema for MySQL", "text": "I’m trying to self-host Temporal v1.29 using Helm. For both default and visibility databases I use MySQL 8.0.45. I get the following error in the manage-schema-visibility-store job: ERROR Unable to update SQL schema. {“error”: “error executing statement: Error 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '“$.TemporalChangeVersion”),\\n ADD COLUMN BinaryChecksums JSON ’ at line 3”, “logging-call-at”: “/home/runner/work/docker-builds/docker-builds/temporal/tools/sql/handler.go:53”} Maybe a smart quote issue? In the source code they seem to be normal quotes though.", "url": "https://github.com/temporalio/temporal/issues/9522", "createdAt": "2026-03-15T13:14:20Z", "updatedAt": "2026-08-13T08:45:00Z", "timestamp": "2026-08-13T08:45:00Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "potential-bug" ], "author": "ByulentMehmed", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:ed62b9dab133c05784ec", "signalId": "github:temporalio/temporal:pull_request:11486", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11486", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Fix approximateSize undercounting on activity start and heartbeat paths", "text": "## What changed? Fixed bookkeeping of mutable state approximate size on the two paths that mutate an `ActivityInfo` without adding its bytes to the counter: `AddActivityTaskStartedEvent` (start), and the heartbeat handler, where `RetryLastWorkerIdentity` now moves into `UpdateActivityProgress`. ## Why? Both sites mutate the pointer `GetActivityInfo` returned, but don't alter the approximate size. ## How did you test it? - [X] built - [ ] run locally and tested manually - [ ] covered by existing tests - [X] added new unit test(s) - [ ] added new functional test(s) ## Potential risks The risk should be low. We will hit the mutable state size limit faster, but it would be proper accounting.", "url": "https://github.com/temporalio/temporal/pull/11486", "createdAt": "2026-08-11T22:57:47Z", "updatedAt": "2026-08-13T08:13:39Z", "timestamp": "2026-08-13T08:13:39Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "reliability-2026" ], "author": "simvlad", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:3e2ba170f74910689200", "signalId": "github:temporalio/temporal:pull_request:11488", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11488", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Drive test retries from attempt results", "text": "Moves retry selection, argument rewriting, and missing-rerun validation from JUnit into a focused retry policy over canonical attempt results. The existing report merge remains presentation-only, isolating this PR to execution policy. Stack: depends on #11514. Canonical history persistence follows this one.", "url": "https://github.com/temporalio/temporal/pull/11488", "createdAt": "2026-08-11T23:31:31Z", "updatedAt": "2026-08-13T08:10:23Z", "timestamp": "2026-08-13T08:10:23Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:81523682a6991d65ff8f", "signalId": "github:temporalio/temporal:pull_request:11514", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11514", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Render crash reports canonically", "text": "Routes the `report-crash` command through the canonical JUnit renderer introduced with attempt results. The command test now compares the parsed document semantically, and the obsolete legacy XML fixture is removed. Stack: depends on #11487. The retry-policy PR follows this one.", "url": "https://github.com/temporalio/temporal/pull/11514", "createdAt": "2026-08-12T22:10:10Z", "updatedAt": "2026-08-13T08:09:50Z", "timestamp": "2026-08-13T08:09:50Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:b935e250cd75fb64b115", "signalId": "github:temporalio/temporal:pull_request:11487", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11487", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Record canonical Go test attempt results", "text": "Runs `go test` directly with JSON output and records package-aware attempt results as the canonical execution facts. The recorder owns event attribution, diagnostics, timeouts, console output, and exact JUnit counters while the existing retry and merge path remains in place as a compatibility seam. Stack: depends on #11512. Canonical crash rendering and retry policy follow this one.", "url": "https://github.com/temporalio/temporal/pull/11487", "createdAt": "2026-08-11T23:31:23Z", "updatedAt": "2026-08-13T08:09:31Z", "timestamp": "2026-08-13T08:09:31Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:b796f399598b3b5a942c", "signalId": "github:temporalio/temporal:pull_request:11533", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11533", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Update test shard salt", "text": "Automatically generated by the optimize-test-sharding workflow.", "url": "https://github.com/temporalio/temporal/pull/11533", "createdAt": "2026-08-13T07:33:14Z", "updatedAt": "2026-08-13T07:33:16Z", "timestamp": "2026-08-13T07:33:16Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "temporal-cicd[bot]", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:ce92c567ac819c3bd74c", "signalId": "github:temporalio/temporal:pull_request:11471", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11471", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Update test shard salt", "text": "Automatically generated by the optimize-test-sharding workflow.", "url": "https://github.com/temporalio/temporal/pull/11471", "createdAt": "2026-08-11T07:30:15Z", "updatedAt": "2026-08-13T07:33:14Z", "timestamp": "2026-08-13T07:33:14Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "temporal-cicd[bot]", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:d6237911e3e80b3897a8", "signalId": "github:temporalio/temporal:pull_request:11355", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11355", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Preserve logger tags across Skip()", "text": "## What changed? `zapLogger.Skip()` now carries the logger's accumulated `tags` into the returned clone, matching the `baseZl` field it already forwarded. Also updated `TestThrottleLogger` to apply a `service` tag *before* the throttled logger wraps it, mirroring what `ThrottledLoggerProvider` does. ## Why? Tags applied before a `Skip()` were silently dropped by the next `With()` call. This regressed in #7945. Before that PR, `With()` did `l.zl.With(fields...)`, so accumulated tags lived inside the zap logger itself — `Skip()` copied `zl`, and the tags came along for free. #7945 changed `With()` to rebuild from the untagged `baseZl` using a new `tags` slice, which made that slice the only surviving record of accumulated tags. `Skip()` was updated to forward the new `baseZl` field but not the new `tags` field, so any `With()` on a Skip'd logger rebuilt from the untagged base and lost everything applied earlier. **Observed on a running server.** Two builds (with and without the fix) started via `make start`, startup logs diffed by `(msg, logging-call-at)` rather than line order. 0/8 Started Worker lines included the service field without the fix, 8/8 with it. Prior to this fix: ````{\"level\":\"info\",\"ts\":\"2026-07-30T08:28:49.544-0700\",\"msg\":\"Started Worker\",\"Namespace\":\"temporal-system\",\"TaskQueue\":\"temporal-sys-tq-scanner-taskqueue-0\",\"WorkerID\":\"temporal-system@127.0.0.1:7239\",\"logging-call-at\":\".../go/pkg/mod/go.temporal.io/sdk@v1.44.0/internal/internal_worker.go:1425\"}```` With the fix: ````{\"level\":\"info\",\"ts\":\"2026-07-30T09:03:02.318-0700\",\"msg\":\"Started Worker\",\"service\":\"worker\",\"Namespace\":\"temporal-system\",\"TaskQueue\":\"temporal-sys-tq-scanner-taskqueue-0\",\"WorkerID\":\"temporal-system@127.0.0.1:7239\",\"logging-call-at\":\".../go/pkg/mod/go.temporal.io/sdk@v1.44.0/internal/internal_worker.go:1425\"}```` Note that `Namespace`, `TaskQueue`, and `WorkerID` are applied by the SDK via `With()` *after* the `Skip()` and survive in both builds, whereas `service` is applied *before* it and hence it is the only field missing. `SdkClientFactoryProvider` wraps `SnTaggedLogger` via `NewSdkLogger`, which calls `Skip()`, and SDK client logs lose `service` when `With()` is called on the supplied logger. `ThrottledLoggerProvider` wraps the same `SnTaggedLogger` identically and loses `service` the same way; that path is what the updated `TestThrottleLogger` covers. `NewReplayLogger` also wraps the same way and is also fixed by the same change, though it has no call sites in this repo. No existing test caught it because `TestThrottleLogger` applied no tags before the `Skip()`, so it passed identically either way. ## How did you test it? - [x] built - [x] run locally and tested manually - [ ] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) ## Potential risks - Log output changes: lines from Skip-wrapping loggers (throttled, SDK, replay) that go through `With()` will now include tags that have been missing since #7945 — most visibly `service`. Anything parsing these logs by exact field set, or alerting on `service` being absent, will see different output. This fix restores pre-#7945 behavior rather than introducing something new.", "url": "https://github.com/temporalio/temporal/pull/11355", "createdAt": "2026-07-30T16:29:05Z", "updatedAt": "2026-08-13T06:35:12Z", "timestamp": "2026-08-13T06:35:12Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "geraldw-ai", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:7447ac377a1d84289f75", "signalId": "github:temporalio/temporal:pull_request:11397", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11397", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Fix constant/error-dependent retry jitter being truncated to a no-op", "text": "## What changed? `addJitter` in `common/backoff/retrypolicy.go` never applied jitter. With a 2s base and `WithJitter(0.1)`, every delay came back as exactly 2.000s instead of spread across `[2.0s, 2.2s)`. ```go // before return duration * time.Duration(1+jitterPct*rand.Float64()) // after return time.Duration(float64(duration) * (1 + jitterPct*rand.Float64())) ```` `1 + jitterPct*rand.Float64()` is a `float64` in `[1.0, 2.0)` for any `jitterPct < 1.0`. Wrapping it in `time.Duration(...)` truncates it to the `integer` 1 _before_ the multiply, so the whole expression collapsed to `duration * 1`. The fix does the arithmetic in float space and converts once at the end, where truncation only drops sub-nanosecond fractions. This free function serves `ConstantDelayRetryPolicy.ComputeNextDelay` and `ErrorDependentRetryPolicy.ComputeNextDelay`. **`ExponentialRetryPolicy` is not affected** — it has its own separate `addJitter` method that works entirely in float space and is correct. Three tests exercised jitter and all three passed against the bug: each asserted `delay >= base && delay < ceiling`, and the buggy value is exactly `base` — the admitted lower bound. Each also took a single sample. All three now sample 1000× and require at least one delay strictly above base, with upper bounds tightened to the true `base*(1+jitterPct)`. `TestAddJitter` also pins `addJitter(d, 0) == d`. ## Why? `WithJitter` is a public builder method that silently did nothing when used as documented. **Latent — no production effect today.** `WithJitter` only writes `p.jitterPct`, which defaults to 0, and at 0 the old and new forms are identical. Its only two call sites are in `retrypolicy_test.go`; `ErrorDependentRetryPolicy` is never constructed outside tests, and `ConstantDelayRetryPolicy`'s one production construction (`namespaceQueueRetryPolicy`, `common/persistence/client/factory.go`) doesn't call it. ## How did you test it? - [x] built - [ ] run locally and tested manually - [x] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) Reverted the fix and confirmed all three strengthened tests fail against the original code (`jitter was never applied; delay stayed at the base value`), then restored it and confirmed that the tests pass. ## Potential risks Low. The change is one line plus test assertions, and it is a no-op at `jitterPct == 0`, which is every production call site today (see above) — so nothing in the server's retry timing moves. Where jitter is enabled, delays now vary within `[base, base*(1+jitterPct))` rather than being pinned to `base` — intended, but it would surface in anything that had come to rely on the constant value. Only the tests changed here did.", "url": "https://github.com/temporalio/temporal/pull/11397", "createdAt": "2026-08-02T14:22:00Z", "updatedAt": "2026-08-13T06:35:10Z", "timestamp": "2026-08-13T06:35:10Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "geraldw-ai", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:0bd585cfbf3cda3c2528", "signalId": "github:temporalio/temporal:pull_request:11531", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11531", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add Schedule V1 to V2 replay and detect coalesced updates", "text": "## Summary - add the offline Schedule V1 history to CHASM replay harness and production sampling tools - associate captured V1 starts with their workflow-task completion - detect an update signal delivered after workflow-task scheduling but before workflow-task start - classify input differences at this boundary as inconclusive rather than a significant V2 divergence - add sanitized workflow-history and controlled-corpus coverage ## Why V1 can consume a timer and update in one workflow task. An event-by-event harness may fire the nominal CHASM deadline before it encounters the update event, producing an old-input versus new-input false positive. ## Production replay evidence The representative request-input case moves from significant to inconclusive with the causal name `v1_workflow_task_input_ordering`. ## Test plan - `go test -tags test_dep ./chasm/lib/scheduler -run \"^(TestWorkflowTaskContainsUpdateBeforeStart|TestDownloadedV1HistoriesAgainstCHASM)$\" -count=1` - representative three-history production replay", "url": "https://github.com/temporalio/temporal/pull/11531", "createdAt": "2026-08-13T06:14:47Z", "updatedAt": "2026-08-13T06:18:20Z", "timestamp": "2026-08-13T06:18:20Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "davidporter-id-au", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:69cf0569cd6409f99219", "signalId": "github:temporalio/temporal:pull_request:11532", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11532", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Reproduce migrated zero catchup compatibility gap", "text": "## Summary - characterize V1 resolution of an explicit zero catchup window to the 10-second minimum - prove migration currently preserves the explicit zero value - pair these tests with existing CHASM coverage where zero resolves to the one-year default ## Finding This is a genuine migration compatibility difference. In the representative history, all 15 CHASM-only actions were decided 10 to 112 seconds after nominal time. V1 dropped them under its 10-second window while CHASM retained them under its default window. This draft intentionally does not choose a fix. A migration-only compatibility rule may be appropriate; globally changing V2 would alter its intended zero-means-unset behavior. ## Test plan - `go test -tags test_dep ./service/worker/scheduler -run \"^TestWorkflow/TestZeroCatchupWindowUsesMinimum$\" -count=1` - `go test -tags test_dep ./chasm/lib/scheduler/migration -run \"^TestLegacyToCreateFromMigrationStateRequest_PreservesZeroCatchupWindow$\" -count=1` - existing CHASM non-positive catchup tests - representative three-history production replay", "url": "https://github.com/temporalio/temporal/pull/11532", "createdAt": "2026-08-13T06:14:55Z", "updatedAt": "2026-08-13T06:14:55Z", "timestamp": "2026-08-13T06:14:55Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "davidporter-id-au", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:173b25f65e3e5acf2f84", "signalId": "github:temporalio/temporal:pull_request:11530", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11530", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Fix Schedule V2 BUFFER_ONE with a deferred start", "text": "## Summary - include an existing deferred BUFFER_ONE start in overlap resolution - prevent a later occurrence from becoming a second buffered start - add a focused regression test with one running, one deferred, and one new occurrence ## Production replay evidence The representative V1 history changed from 5,355 V1 actions versus 4,961 CHASM actions to 5,355 versus 5,355. Extra and missing workflow identities disappeared; only observation-time differences remain. ## Test plan - `go test -tags test_dep ./chasm/lib/scheduler -run \"^TestProcessBufferTask_BufferOne(KeepsExistingDeferredStart)?$\" -count=1` - representative three-history production replay", "url": "https://github.com/temporalio/temporal/pull/11530", "createdAt": "2026-08-13T06:14:42Z", "updatedAt": "2026-08-13T06:14:42Z", "timestamp": "2026-08-13T06:14:42Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "davidporter-id-au", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:f64b419b9e7ef0e6eaa0", "signalId": "github:temporalio/temporal:pull_request:11463", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11463", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Schedule v2 replay fidelity", "text": "## 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? - [ ] built - [ ] run locally and tested manually - [ ] covered by existing tests - [ ] added new unit test(s) - [ ] added new functional test(s) ## Potential risks _Any change is risky. Identify all risks you are aware of. If none, remove this section._", "url": "https://github.com/temporalio/temporal/pull/11463", "createdAt": "2026-08-10T23:31:02Z", "updatedAt": "2026-08-13T06:05:16Z", "timestamp": "2026-08-13T06:05:16Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "davidporter-id-au", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:bdac1051a7b5b7ef647d", "signalId": "github:temporalio/temporal:pull_request:11470", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11470", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Jwt audience env config", "text": "## What changed? Added TEMPORAL_JWT_AUDIENCE to the embedded and Docker configuration templates, mapping the environment variable to global.authorization.audience. ## Why? JWT audience validation needs to be configurable in environment-based deployments, consistent with the existing JWT authorization settings. ## How did you test it? - [x] built - [ ] run locally and tested manually - [x] covered by existing tests - [ ] added new unit test(s) - [ ] added new functional test(s) ## Potential risks An incorrect TEMPORAL_JWT_AUDIENCE value can cause JWT-authenticated requests with a different audience to be rejected. When unset, it defaults to an empty value, preserving existing configuration behavior.", "url": "https://github.com/temporalio/temporal/pull/11470", "createdAt": "2026-08-11T05:31:35Z", "updatedAt": "2026-08-13T05:08:21Z", "timestamp": "2026-08-13T05:08:21Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "wtg-peternguyen", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:06bc882af3ef42f8c2e7", "signalId": "github:temporalio/temporal:pull_request:11529", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11529", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "JWT audience env config", "text": "## What changed? Added TEMPORAL_JWT_AUDIENCE to the embedded and Docker configuration templates, mapping the environment variable to global.authorization.audience. ## Why? JWT audience validation needs to be configurable in environment-based deployments, consistent with the existing JWT authorization settings. ## How did you test it? - [x] built - [ ] run locally and tested manually - [x] covered by existing tests - [ ] added new unit test(s) - [ ] added new functional test(s) ## Potential risks An incorrect TEMPORAL_JWT_AUDIENCE value can cause JWT-authenticated requests with a different audience to be rejected. When unset, it defaults to an empty value, preserving existing configuration behavior.", "url": "https://github.com/temporalio/temporal/pull/11529", "createdAt": "2026-08-13T05:08:07Z", "updatedAt": "2026-08-13T05:08:09Z", "timestamp": "2026-08-13T05:08:09Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "wtg-peternguyen", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:4862b7ced2c51a44742d", "signalId": "github:temporalio/temporal:pull_request:11493", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11493", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "fix(activity): close standalone activity as TIMED_OUT instead of FAILED on worker-reported schedule timeout", "text": "## What changed? A worker reporting a schedule-to-start/close timeout via RespondActivityTaskFailed[ById] now closes a standalone (CHASM) activity as TIMED_OUT instead of FAILED, mirroring the timer-queue path and the workflow-activity behavior. The reported failure's Cause, if present, is preserved on the timeout outcome, otherwise prior attempt's failure is used as the cause. The specific changes are as follows: HandleFailed: route these timeouts to TransitionTimedOut timeoutEvent: add optional cause, preferred over the prior attempt's failure tests: parity coverage for the by-ID timeout and cause-preservation path ## Why? This is for parity with workflow activity, which was changed in PR #9132 to return retry state of TIMEOUT instead of NON_RETRYABLE_FAILURE when the schedule to close or schedule to start timeout causes the activity to close. In the case of standalone activity, the worker-reported schedule-to-start or schedule-to-close timeout should behave similarly. ## How did you test it? - [x] built - [ ] run locally and tested manually - [ ] covered by existing tests - [ ] added new unit test(s) - [x] added new functional/activity parity test(s)", "url": "https://github.com/temporalio/temporal/pull/11493", "createdAt": "2026-08-12T05:17:58Z", "updatedAt": "2026-08-13T05:05:11Z", "timestamp": "2026-08-13T05:05:11Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "ks-temporal", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:561feba6cf17f57e3d7b", "signalId": "github:temporalio/temporal:pull_request:11465", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11465", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add isolated functional test clusters", "text": "## Summary - give every testcore.NewEnv test a fresh cluster and tear it down with the test - bound concurrently live clusters to GOMAXPROCS by default, configurable with TEMPORAL_TEST_LIVE_CLUSTERS - preseed the primary and external namespaces for each cluster before server startup - preserve bounded legacy suite-owned cluster paths and suite-level worker-service requirements - retain lightweight optional JSONL lifecycle, boot-phase, runtime, and RSS reporting - build on #10643 for the lower-resource CI shard layout and its persistence prerequisites The shared pool, dedicated-cluster marker, warm spares, duplicate SQL/SQLite lease work, Cassandra reuse pool, and heavyweight report generator are intentionally removed from this PR. FASTBOOT.md retains the investigation history and current conclusions. ## Testing - make fmt lint - go test -race -tags=test_dep ./tests/testcore - go test -race -tags=test_dep ./tests -run ^TestClientDataConverterTestSuite$ -count=1 - go test -race -tags=test_dep ./tests -run ^TestWorkflowAliasSearchAttributeTestSuite$ -count=1", "url": "https://github.com/temporalio/temporal/pull/11465", "createdAt": "2026-08-11T02:58:59Z", "updatedAt": "2026-08-13T02:55:03Z", "timestamp": "2026-08-13T02:55:03Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "test-all-dbs" ], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:bb468dca984a61d7bd83", "signalId": "github:temporalio/temporal:pull_request:10643", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:10643", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Downscale test runner size, increase shards", "text": "## What changed? Only use 4-core ARM runners instead of 8-core; and increase shard size for test sharding. ## Why? 8-core runners have - at least during peak hours - very long provisioning time (several minutes). By using 4-core we reduce that time, but risk OOM kills as they have less memory. To counter that, we increase the number of test shards so that fewer tests are run per shard.", "url": "https://github.com/temporalio/temporal/pull/10643", "createdAt": "2026-06-10T17:58:11Z", "updatedAt": "2026-08-13T02:55:03Z", "timestamp": "2026-08-13T02:55:03Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "test-all-dbs" ], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:2eb5368f644ef2ed61ec", "signalId": "github:temporalio/temporal:pull_request:11474", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11474", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Reduce functional test scheduler worker counts", "text": "## What changed? Reduced worker counts in tests. ## Why? \"Screenshot", "url": "https://github.com/temporalio/temporal/pull/11474", "createdAt": "2026-08-11T14:56:41Z", "updatedAt": "2026-08-13T02:55:00Z", "timestamp": "2026-08-13T02:55:00Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "test-all-dbs", "reliability-2026" ], "author": "stephanos", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:ada847a6ae4e64f25577", "signalId": "github:temporalio/temporal:issue:10841", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:issue:10841", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "SignalWithStart hangs forever on an orphaned current-execution pointer", "text": "## Expected Behavior `SignalWithStartWorkflowExecution` for a workflow ID makes progress: it either signals the running execution or starts a new run, and returns within the client deadline. I suppose, but haven't checked, that this behavior could occur in other APIs which interacts with current executions in a similar fashion (Continue As New?, Updates?, ...) ## Actual Behavior We have observed that `SignalWithStart` API call for **one** workflow ID to fail consistently with `context deadline exceeded` error, across multiple calling services, indefinitely. Other workflows are unaffected. What we found is that that workflow is in a corrupt state in Cassandra: the current-execution pointer row (sentinel `permanentRunID`) is here, but the mutable state and history of the run it points to are both gone. Reading the rows on the owning shard shows the pointer present, zero mutable-state rows for the referenced run, and zero history nodes. The pointer's decoded `execution_state` names a run that completed with status `TIMED_OUT`. Running an `AdminService`'s `DeleteWorkflowExecution` API call on the workflow ID / run ID cleared up the dangling row and let the `SignalWithStart` API call succeed afterwards. Here is the reasoning of what could happen: `SignalWithStart` [resolves the current run from the pointer](https://github.com/temporalio/temporal/blob/v1.30.4/service/history/api/signalwithstartworkflow/api.go#L37-L45), then [loads that run's mutable state](https://github.com/temporalio/temporal/blob/v1.30.4/service/history/api/consistency_checker.go#L298). The [load returns NotFound, so the call treats it as \"no current execution\"](https://github.com/temporalio/temporal/blob/v1.30.4/service/history/api/signalwithstartworkflow/api.go#L50-L51) and takes the [brand-new path (`CreateWorkflowModeBrandNew`)](https://github.com/temporalio/temporal/blob/v1.30.4/service/history/api/signalwithstartworkflow/signal_with_start_workflow.go#L234). That insert is [conditioned on `IF NOT EXISTS` for the current row](https://github.com/temporalio/temporal/blob/v1.30.4/common/persistence/cassandra/mutable_state_store.go#L49), which still exists, so it [fails with `CurrentWorkflowConditionFailedError`](https://github.com/temporalio/temporal/blob/v1.30.4/common/persistence/cassandra/errors.go#L185-L215). The [handler retries, hits the same condition, and loops](https://github.com/temporalio/temporal/blob/v1.30.4/service/history/handler.go#L1057-L1070) until the client deadline. No path reconciles a present pointer against a missing target run, so the call never succeeds. ## Steps to Reproduce the Problem 1. Create and complete a workflow so a current-execution pointer exists for run X. 1. At the persistence layer, delete the mutable-state row and history nodes for run X, but leave the current-execution pointer row intact. 1. Call `SignalWithStartWorkflowExecution` for that workflow ID, and observe it retry internally and fail with a deadline. ## Specifications - Version: v1.30.4 - Platform: Self hosted, backed by Cassandra ## Additional Context We suspect the pointer row was resurrected at the persistence layer. Looking at the code it seems workflow deletions removes the pointer before the mutable state and history, so a partial failure would leave the pointer gone, not surviving, and to the best of my knowledge, no code seems to writes the pointer for a closed workflow. The likely mechanism is Cassandra deleted-row resurrection: the pointer's tombstone expired before every replica compacted it, and a later repair streamed the pre-delete pointer back while the mutable-state and history tombstones stuck. The specific workflow we observed behavior on is over a year old, which is ample time for that to happen.", "url": "https://github.com/temporalio/temporal/issues/10841", "createdAt": "2026-06-25T09:58:11Z", "updatedAt": "2026-08-13T02:54:24Z", "timestamp": "2026-08-13T02:54:24Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "potential-bug" ], "author": "lminaudier", "state": "open", "assignees": [ "yycptt" ], "change": "updated" } }, { "id": "event:d65d865e6ee8a26c9262", "signalId": "github:temporalio/temporal:pull_request:11528", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11528", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Improve flaky report presentation", "text": "## What changed? - Shows Bayesian commit suspects directly below the overall stats. - Separates synthetic test-runner timeouts from test failures and reports affected artifacts. - Shows final-retry test failures as affected-artifact counts rather than workflow-run rates. ## Why? The synthetic `testrunner.TotalTimeout` event was reported both as a flaky test and as a CI breaker, while the former CI-breaker percentage mixed artifact and workflow-run units. ## How did you test it? - `go test -tags test_dep ./tools/flakereport ./tools/common/github` - `make lint-code` ## Potential risks This changes report categorization and presentation only; raw `failures.json` retains synthetic timeout records as timeout events.", "url": "https://github.com/temporalio/temporal/pull/11528", "createdAt": "2026-08-13T01:43:14Z", "updatedAt": "2026-08-13T02:52:39Z", "timestamp": "2026-08-13T02:52:39Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "chaptersix", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:44deb0381b405d9bf52d", "signalId": "github:temporalio/temporal:issue:11314", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:issue:11314", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "Replace LeveledCompactionStrategy (LCS) with Cassandra 5.x default UnifiedCompactionStrategy (UCS) in schema.cql", "text": "**Description** The Cassandra schema file [/cassandra/temporal/schema.cql](https://github.com/temporalio/temporal/blob/main/schema/cassandra/temporal/schema.cql) currently configures nearly all tables with LeveledCompactionStrategy (LCS). LCS is not a good general-purpose default — it's optimized for read-heavy workloads with low write amplification tolerance, and imposes unnecessary compaction overhead for tables that don't need it. Cassandra 5.0 introduces UnifiedCompactionStrategy (UCS) as the new default, which is designed to work well as a general-purpose strategy across a broader range of workloads. **Describe the solution you'd like** Remove the explicit WITH COMPACTION = {...} clause from each table definition in schema.cql. Dropping the clause lets each table fall back to the engine's default compaction strategy: On Cassandra 5.x, this will default to UnifiedCompactionStrategy (UCS). On earlier Cassandra versions, this will default to SizeTieredCompactionStrategy (STCS), so backward compatibility is preserved. This avoids hardcoding a compaction strategy choice in the schema and lets each Cassandra version apply its own sensible default.", "url": "https://github.com/temporalio/temporal/issues/11314", "createdAt": "2026-07-27T18:59:24Z", "updatedAt": "2026-08-13T02:50:29Z", "timestamp": "2026-08-13T02:50:29Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "enhancement" ], "author": "bschoening", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:59ce8c373d547364b607", "signalId": "github:temporalio/temporal:pull_request:11524", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11524", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Index GitHub Actions runs for flake bisecting", "text": "## What changed? - Build one index from parsed test attempts keyed by normalized test name and GitHub Actions run commit. - Reuse that index when selecting and bisecting tests instead of rescanning every parsed attempt for each candidate. - Use `githubActions...` names in the bisect path to distinguish GitHub Actions runs from Temporal workflows. ## Why? A report can contain millions of parsed attempts. The previous bisect loop rescanned all of them for every candidate test. ## How did you test it? - [x] covered by existing tests - [x] checked the diff for whitespace errors - [ ] built - [ ] run locally and tested manually - [ ] added new unit test(s) - [ ] added new functional test(s) ## Potential risks This is stacked on #11523. The index preserves full test counts for qualification while excluding attempts without an in-range GitHub Actions commit from commit observations, matching the previous behavior.", "url": "https://github.com/temporalio/temporal/pull/11524", "createdAt": "2026-08-13T00:56:37Z", "updatedAt": "2026-08-13T02:35:47Z", "timestamp": "2026-08-13T02:35:47Z", "metrics": { "reactions": 1, "comments": 1 }, "labels": [], "author": "chaptersix", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:9697a6451cf9260d7d5b", "signalId": "github:temporalio/temporal:pull_request:11523", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11523", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Use Go client for flaky report GitHub API calls", "text": "## What changed? - Replace the `gh api` subprocesses used by `flakereport` with a shared Go HTTP client. - Rate-limit GitHub API requests to 10 RPS by default; allow an explicit `--rps` override. - Stream artifact downloads to temporary files while preserving the existing 60-second download deadline and artifact worker pool. ## Why? The report performs a GitHub API request for every artifact. Avoiding a new `gh` process for each request removes that per-request overhead without adding a more complex processing pipeline. ## How did you test it? - [x] added new unit test(s) - [x] checked the diff for whitespace errors - [ ] built - [ ] run locally and tested manually - [ ] covered by existing tests - [ ] added new functional test(s) ## Potential risks The client uses the existing `GH_TOKEN`/`GITHUB_TOKEN` environment variables, falling back to one `gh auth token` call. Transient API errors are surfaced to the existing per-artifact error handling rather than retried.", "url": "https://github.com/temporalio/temporal/pull/11523", "createdAt": "2026-08-13T00:56:33Z", "updatedAt": "2026-08-13T02:35:47Z", "timestamp": "2026-08-13T02:35:47Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "chaptersix", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:60c134e29656b872f295", "signalId": "github:temporalio/temporal:issue:6173", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:issue:6173", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "Schedule \"StartAt\" not used when calculating intervals?", "text": "Today is _June 19th, 2024_. If you create a schedule and specify \"every 365 days\" the result will be that the first run is on `2024-12-18 00:00:00`. **That's in 6 months**. I've tried passing `StartAt: 2025-06-19` but I get `2025-12-18 00:00:00` as a result. I understand this may be known and as-designed behavior but it struck me as unexpected to ask for a 365 day interval, yet the first run is within the next 6 months. I also don't see any way to achieve my desired result. Am I missing anything? _EDIT_: I also can't use the _offset_ to control this behavior because I don't know what the final calculation will be until the schedule is created. ## Expected Behavior In the example above, I'd prefer to have the schedule's first run be at my specified \"StartAt\". So, if I say: \"Start this workflow every 365 days with start at 2025-02-03 04:05:06\", then the upcoming runs would look like: * 2025-02-03 04:05:06 * 2026-02-03 04:05:06 * 2027-02-03 04:05:06 * etc. ## Actual Behavior When I pick 365 days as the interval, I seem to be getting a date 6 months in the future. ## Steps to Reproduce the Problem 1. Go to temporal UI and add a schedule. 1. Choose 365 days and save. 1. Check the schedule's upcoming runs. ## Specifications - Version: - Platform:", "url": "https://github.com/temporalio/temporal/issues/6173", "createdAt": "2024-06-19T17:59:22Z", "updatedAt": "2026-08-13T02:35:05Z", "timestamp": "2026-08-13T02:35:05Z", "metrics": { "reactions": 1, "comments": 0 }, "labels": [ "potential-bug" ], "author": "nunofgs", "state": "open", "assignees": [ "chaptersix" ], "change": "updated" } }, { "id": "event:872b1c3120ab1de59595", "signalId": "github:temporalio/temporal:issue:10579", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:issue:10579", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "Schedule deadlocks after Workflow ID reuse when previous scheduled action has Workflow Retry chain", "text": "## Temporal version - Temporal Server: 1.31.0 - Persistence: PostgreSQL - Visibility: Elasticsearch ## Summary A Schedule's internal scheduler Workflow can become permanently blocked in `refreshWorkflows` when: 1. A Schedule-started Workflow has a Workflow-level Retry Policy. 2. The scheduled execution exhausts retries, producing a multi-run chain ending in failure. 3. A separate manual execution reuses the Schedule-generated Workflow ID that has a multi-run chain. 4. The next scheduled action attempts to refresh the previous action. The scheduler watcher repeatedly fails with: ```text WatchWorkflow: last event did not have correct attrs ``` The Schedule stops launching actions. Pause/unpause signals do not recover it because the scheduler Workflow remains blocked waiting for an endlessly retried local activity. ## Reproduction Create a Schedule like: ```go ScheduleActionStartWorkflow{ ID: \"example\", Workflow: ExampleWorkflow, RetryPolicy: &temporal.RetryPolicy{ MaximumAttempts: 3, }, } ``` Use default Skip overlap policy. The Schedule generates a Workflow ID like: ```text example-2026-06-03T12:20:00Z ``` Steps: 1. Make the scheduled Workflow fail through all three Workflow retry attempts. 2. Before the next scheduled tick, manually start a separate Workflow execution using the exact generated ID: ```text example-2026-06-03T12:20:00Z ``` 3. Wait for the next scheduled tick. ## Expected behavior The scheduler identifies the previous scheduled chain as closed, records terminal status, and starts/skips the next action normally. ## Actual behavior The Schedule becomes permanently stuck: ```text recent action status: RUNNING actual scheduled Workflow chain status: FAILED RunningWorkflows: [] bufferSize: 1 next action time: in past ``` Internal scheduler stack: ```text refreshWorkflows processWatcherResult WatchWorkflow ``` Internal scheduler history repeatedly records: ```text WatchWorkflow: last event did not have correct attrs ``` Pause/unpause signals are accepted into history but are not processed. ## Root cause analysis Scheduled retry chain: ```text Run A — Continue-As-New Run B — Continue-As-New Run C — Failed ``` Scheduler tracks: ```text WorkflowId: example-2026-06-03T12:20:00Z FirstExecutionRunId: Run A ``` Manual execution creates a newer independent chain with the same Workflow ID: ```text Run D — separate FirstExecutionRunId ``` Watcher first queries latest execution by Workflow ID without Run ID: ```go Execution: &commonpb.WorkflowExecution{WorkflowId: ex.WorkflowId}, FirstExecutionRunId: ex.RunId, ``` Latest execution is manual Run D. Watcher detects a different chain and follows the scheduled chain using its first Run ID: ```go if pollRes.FirstExecutionRunId != req.FirstExecutionRunId { if len(req.Execution.RunId) == 0 { return nil, errFollow(req.FirstExecutionRunId) } } ``` The resulting response combines: ```text WorkflowStatus: FAILED Close event: WORKFLOW_EXECUTION_CONTINUED_AS_NEW ``` Status represents the terminal retry chain, while the close event belongs to the initial run. `responseBuilder.Build` branches on `FAILED`, expects failed-event attributes, receives a Continue-As-New event, then returns `errNoAttrs`: ```go case enumspb.WORKFLOW_EXECUTION_STATUS_FAILED: if attrs := event.GetWorkflowExecutionFailedEventAttributes(); attrs == nil { return nil, errNoAttrs } ``` The local activity retries forever, blocking the scheduler Workflow. ## Relevant source - Wrong-chain fallback: https://github.com/temporalio/temporal/blob/v1.31.0/service/worker/scheduler/activities.go#L143-L151 - Close-event interpretation: https://github.com/temporalio/temporal/blob/v1.31.0/service/worker/scheduler/activities.go#L302-L349 - Blocking refresh: https://github.com/temporalio/temporal/blob/v1.31.0/service/worker/scheduler/workflow.go#L1544-L1558 ## Suggested fix When following `FirstExecutionRunId`, ensure `PollMutableState` status and fetched close event refer to the same terminal execution. Also make `errNoAttrs` non-retryable or otherwise prevent `WatchWorkflow` from permanently blocking Schedule processing.", "url": "https://github.com/temporalio/temporal/issues/10579", "createdAt": "2026-06-06T18:19:39Z", "updatedAt": "2026-08-13T02:34:12Z", "timestamp": "2026-08-13T02:34:12Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "tianrendong", "state": "open", "assignees": [ "chaptersix" ], "change": "updated" } }, { "id": "event:c01e10eb16be27a24146", "signalId": "github:temporalio/temporal:pull_request:11527", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11527", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Fix sticky queue stats zeroed out", "text": "## What Skip the versioning attribution logic when computing stats for sticky queues. Otherwise, we end up with 0 value for add and dispatch rates. This breaks poller autoscaling for sticky queues: 0/0 = NaN, and NaN > threshold is always false, so no +1 scaling signals are ever emitted. Background DescribeTaskQueue returns stats like add_rate and dispatch_rate. For versioned task queues, these stats are obtained from the unversioned physical queue. So when we query the stats for the unversioned queue, we subtract the stats already attributed to the versioned queue. This way, we don't double count. Sticky queues on the other hand are not versioned; they only have the unversioned physical queue. So the above logic is not applicable. Since sticky queue inherits the user data from the normal queue, it was incorrectly treated as versioned. ## How did you test it? Unit tests 🤖 Generated with [Claude Code](https://claude.com/claude-code)", "url": "https://github.com/temporalio/temporal/pull/11527", "createdAt": "2026-08-13T01:42:36Z", "updatedAt": "2026-08-13T02:34:09Z", "timestamp": "2026-08-13T02:34:09Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "rkannan82", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:e2c4f4de63e975085684", "signalId": "github:temporalio/temporal:issue:8490", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:issue:8490", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "Scheduled Actions doesn't clear ContinuedFailure on null success payloads", "text": "## Expected Behavior - When a scheduled action succeeds, subsequent scheduled actions should not receive a `ContinuedFailure` failure payload. ## Actual Behavior - If a scheduled action fails, setting `ContinuedFailure`'s payload, and then a subsequent scheduled action succeeds without returning a payload (a `null` payload), `ContinuedFailure` will continue to propagate to scheduled actions.", "url": "https://github.com/temporalio/temporal/issues/8490", "createdAt": "2025-10-15T21:10:47Z", "updatedAt": "2026-08-13T02:30:09Z", "timestamp": "2026-08-13T02:30:09Z", "metrics": { "reactions": 2, "comments": 2 }, "labels": [ "bug", "schedules" ], "author": "lina-temporal", "state": "open", "assignees": [ "chaptersix" ], "change": "updated" } }, { "id": "event:442e6d64d6366a8ecebb", "signalId": "github:temporalio/temporal:issue:8087", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:issue:8087", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "[Scheduled Actions] Skipped Action Metric", "text": "**Is your feature request related to a problem? Please describe.** We'd like to have a metric for whenever schedules skip a scheduled run for any reason (either by overlap policy, missing the catchup window, or from a buffer overrun). **Describe the solution you'd like** - A new metric is introduced to keep track of skipped scheduled runs. **Describe alternatives you've considered** - Changes to record skipped schedules in a schedule's visibility record and/or the memo would still necessitate polling to record and alarm on their values. **Additional context** - Customers would like to alarm on when a scheduled run was missed or skipped.", "url": "https://github.com/temporalio/temporal/issues/8087", "createdAt": "2025-07-22T21:24:56Z", "updatedAt": "2026-08-13T02:29:28Z", "timestamp": "2026-08-13T02:29:28Z", "metrics": { "reactions": 1, "comments": 1 }, "labels": [ "enhancement", "feature-request", "schedules" ], "author": "lina-temporal", "state": "open", "assignees": [ "chaptersix" ], "change": "updated" } }, { "id": "event:af5fd5e522687da037d3", "signalId": "github:temporalio/temporal:pull_request:11204", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11204", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Stabilize mixed-brain server rolls", "text": "## Summary - roll four mixed-version server instances while OMES workloads run - retain each instance's port allocation across replacements and verify membership convergence - route through a mutable frontend proxy and add proxy lifecycle coverage - temporarily resolve OMES from the exact commit in temporalio/omes#426; replace this with the upstream pseudo-version after it merges ## Root cause Replacement dev servers were allocated new ports, leaving clients able to dial departed frontend addresses. ## Validation - go test -tags test_dep ./devserver (OMES) - go test -tags test_dep -run TestFrontendProxy . (mixedbrain) - make lint-code - PERSISTENCE_DRIVER=postgres12 MIXED_BRAIN_TEST_DURATION=2m make mixed-brain-test", "url": "https://github.com/temporalio/temporal/pull/11204", "createdAt": "2026-07-22T02:30:06Z", "updatedAt": "2026-08-13T02:19:58Z", "timestamp": "2026-08-13T02:19:58Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "chaptersix", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:dcc3a63e0ec9c1e1300e", "signalId": "github:temporalio/temporal:pull_request:11419", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11419", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Improve flaky-test report collection and bisecting", "text": "## What changed? - Add a rate-limited GitHub API client for efficiently retrieving workflow, artifact, and commit data. - Aggregate test runs once and reuse the index for report generation and bisect analysis. - Add parallel processing and coverage for API handling, aggregation, parsing, and report/bisect behavior. ## Why? The flaky-test report needs to process a large workflow history without redundant work or exceeding GitHub API limits. ## How did you test it? - [x] added new unit test(s) - [x] checked the diff for whitespace errors - [ ] built - [ ] run locally and tested manually - [ ] covered by existing tests - [ ] added new functional test(s) ## Potential risks GitHub API changes may still encounter unexpected response or rate-limit behavior at production scale; the client applies bounded concurrency, retries, and cooldowns.", "url": "https://github.com/temporalio/temporal/pull/11419", "createdAt": "2026-08-04T23:31:25Z", "updatedAt": "2026-08-13T02:17:27Z", "timestamp": "2026-08-13T02:17:27Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "chaptersix", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:ff06b4daf18477eaf583", "signalId": "github:temporalio/temporal:pull_request:11461", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11461", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Standardize Claude review comments", "text": "Standardize Claude review comment format, style and focus.", "url": "https://github.com/temporalio/temporal/pull/11461", "createdAt": "2026-08-10T22:54:30Z", "updatedAt": "2026-08-13T02:04:53Z", "timestamp": "2026-08-13T02:04:53Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:4e0cd7ca84b9ac6f7f36", "signalId": "github:temporalio/temporal:pull_request:11480", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11480", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Extract shared JUnit XML handling", "text": "## What changed? Extract generic JUnit XML file reading and writing into `tools/common/junit`. ## Why? Centralizing format-level JUnit handling.", "url": "https://github.com/temporalio/temporal/pull/11480", "createdAt": "2026-08-11T20:57:07Z", "updatedAt": "2026-08-13T02:03:46Z", "timestamp": "2026-08-13T02:03:46Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "request-claude-review" ], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:d26101ceaf22fb8e70e0", "signalId": "github:temporalio/temporal:pull_request:11482", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11482", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Cleanup/consolidate completionHandler test infra", "text": "## What changed? When trying to clean up some PRs for worker callbacks, I noticed some unnecessary duplication and cruft in our testcases for completion handlers. Essentially it's this: \"image\" Rather than having N places where we construct a `completionHandler` and several implementations of spinning up an `httptest` webserver, we now just have a single `newNexusCompletionHandler` function that does both. ## Why? Remove boilerplate, making tests more concise and easier to read. ## How did you test it? - [x] built - [x] run locally and tested manually - [ ] covered by existing tests - [ ] added new unit test(s) - [ ] added new functional test(s) ## Potential risks If there was some subtle behavioral change this could undermine our testing.", "url": "https://github.com/temporalio/temporal/pull/11482", "createdAt": "2026-08-11T22:40:23Z", "updatedAt": "2026-08-13T02:02:03Z", "timestamp": "2026-08-13T02:02:03Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "chrsmith", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:a2e9bacc2df1efe7a292", "signalId": "github:temporalio/temporal:pull_request:11479", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11479", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "replication: emit source_task_id and source_cluster on passive-side lifecycle events", "text": "## What Emits `source_cluster`, `source_shard`, and `source_task_id` on the `executing` and `applied` phases of the `replication_lifecycle` wide event, not just `sent`. ## Why `source_task_id` was already on the wire (`ReplicationTask.source_task_id`, populated at every `raw_task_converter.go` conversion site) and already stored on the task as `ExecutableTaskImpl.taskID` — which is also the watermark the receiver acks back. It was simply never emitted on the passive side, so a `sent` event on the active cluster could not be joined to the matching apply. Observability only: no proto change, no wire-format change, no version gating. ## Details - `common/wideevents`: added `SourceCluster` and `SourceShard`; moved `SourceTaskID` out of the sent-only group so all three are emitted phase-independently, guarded so they are absent when unset. - `common/wideevents/context.go`: `ReplicationTaskOrigin{ShardID, TaskID}` carries source provenance to the NDC `applied` emitter, which sits below the engine boundary and has no task in scope. Diagnostic only — never affects control flow. - Emitters populate the fields for `sync_versioned_transition`, `verify_versioned_transition`, and `sync_workflow_state`. **The join key is `(source_cluster, source_shard, source_task_id)` — the id alone is not unique.** Task ids are allocated per source shard from overlapping ranges. On a 4-shard xdc run with 6 workflows, 4 of 19 distinct `source_task_id`s appeared on more than one source shard, so this matters in any multi-shard deployment. The passive side gets the shard directly from `SourceShardKey()` (the stream receiver is created per source-shard pair); no reversal of `generateShardIDs` is involved, and that reversal would be ambiguous anyway when shard counts differ between clusters. `source_task_id` is intentionally absent on the two on-demand paths — the `SyncState` resend and child-completion verification — which re-fetch the artifact from the source, so the triggering task is not the one whose payload was applied. Emitting its id would create a false join. `source_shard` and `source_cluster` are still set on the resend path, since the source shard is known there. In queries, `applied AND source_task_id IS NULL` therefore isolates resend-originated applies. ## Test `go build ./...`, plus `common/wideevents`, `service/history/replication`, and `service/history/ndc` unit tests. `TestReplicationLifecycleFieldSetLocked` pins the new field set. Verified end to end on a two-cluster, 4-shard xdc harness (scaffolding not committed), asserting on every captured event that `source_shard` is present and non-zero, that it spans multiple distinct shards (so the assertion cannot pass on a constant), and that every passive `(source_shard, source_task_id)` pair matches a `sent` event the active side actually emitted on that shard: ``` source_shard present on all 71 replication_lifecycle events source_shard spans 3 distinct shards 4 sent source_task_ids appear on more than one source_shard (of 19 distinct ids) (source_shard, source_task_id) joined to a sent event on 48 passive events ``` Note there is no CI coverage that the emitters populate the fields — only that the payload can. Happy to add a unit test on payload construction if preferred. 🤖 Generated with [Claude Code](https://claude.com/claude-code)", "url": "https://github.com/temporalio/temporal/pull/11479", "createdAt": "2026-08-11T19:36:24Z", "updatedAt": "2026-08-13T02:01:25Z", "timestamp": "2026-08-13T02:01:25Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation", "reliability-2026" ], "author": "michaely520", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:6c68ba0edc4cefe4a1ec", "signalId": "github:temporalio/temporal:pull_request:11459", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11459", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Record what a replication task carried on the sent lifecycle event", "text": "A `sent` event records that a task went out, not *what it carried* — and that can't be recovered afterwards. `LastUpdateVersionedTransition` stamps are overwritten by later transitions, and the replication progress cache that supplies the lower bound of both the state diff and the event range is in-memory and per `(run, target)`. Seven sent-only fields: - `target_cluster` — scopes the bounds, since progress is cached per target - `priority` — the stream the task went out on - `artifact_kind` — snapshot vs mutation - `exclusive_start_versioned_transition` — the mutation's exclusive lower bound - `hydrated_versioned_transition` — the versioned transition of the state actually serialized - `shipped_first_event_id` / `shipped_last_event_id` — the event ids actually carried Note `hydrated_versioned_transition` is `>=` the task's own versioned transition whenever the sender advanced past the queued task, so the existing `transition_count` describes the queue entry while this describes the payload. Likewise `shipped_*_event_id` are the events carried, distinct from `first_event_id`/`next_event_id`, which are the task's own range. `priority` is only known to the sender: it is assigned per send loop, and only the low-priority stream is rate limited, while flow control, trackers and ack watermarks are all per priority. Without it a backed-up stream can't be attributed. Also populates `failover_version`/`transition_count` on the `sync_versioned_transition` applied event; the `!= 0` guard dropped them, leaving sent→applied uncorrelatable. All values are read from the task at the existing emit site, so no interfaces change and the send path is untouched. Everything stays behind `history.emitReplicationLifecycleEvents`. Verified end-to-end against a live two-cluster replication stream. 🤖 Generated with [Claude Code](https://claude.com/claude-code)", "url": "https://github.com/temporalio/temporal/pull/11459", "createdAt": "2026-08-10T21:33:05Z", "updatedAt": "2026-08-13T02:01:07Z", "timestamp": "2026-08-13T02:01:07Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation", "reliability-2026" ], "author": "michaely520", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:d3522b0c0eb8f18fae5a", "signalId": "github:temporalio/temporal:pull_request:11401", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11401", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Emit handover watermark and shard readiness wide events", "text": "## What changed? Adds `NamespaceLifecycle` wide events on the two paths that decide when a namespace handover can complete. Also threads `ShardID` and an `EventLogger` into `HandoverTrackerParams` so the tracker can attribute an event to its shard. **Shard handover tracker** (`service/history/shard/`) — each shard holds its own replication watermark for a namespace in handover, and the handover cannot complete until every shard's watermark has been acked by the target: | Phase | When | |---|---| | `shard_handover_watermark_set` | the shard takes or advances a watermark — `reason` is `added` or `updated` | | `shard_handover_watermark_removed` | the shard drops it — `deleted_from_db` separates a namespace deletion from a normal exit out of handover | Both fire only on an actual mutation of the tracker map. Notably, the non-handover branch of `UpdateHandoverState` runs for *every* namespace notification on *every* shard; it now guards on presence before deleting, so it emits only on a real removal rather than on every notification. **`WaitHandover`** (`service/worker/migration/`) — one event, emitted on the way out: | Phase | When | |---|---| | `shard_handover_incomplete` | the wait ended with shards still behind | Carries `not_ready_count`, `total_shards`, `missing_handover_info_count`, `max_lagging_tasks{,_shard_id}`, `elapsed_seconds`, `exit_reason`, and a `lagging_shards` list of `{shard_id, lagging_tasks}` capped at 64 (`not_ready_count` is always the true count). A handover that completes leaves no laggards and emits nothing, so the happy path — nearly all of them — is silent. The wait is capped at `maximumHandoverTimeoutSeconds` (30) with `MaximumAttempts: 1`, so this is at most one event per handover. `exit_reason` separates the wait being killed while shards were still behind from a failed `GetReplicationStatus`. The activity never returns on its own in the former case: the SDK cancels the activity context off the heartbeat, the next `GetReplicationStatus` fails, `WaitHandover` returns, and the deferred summary runs. A not-ready shard with `lagging_tasks == 0` is the missing-handover-info case (that shard's namespace cache hasn't picked up the handover yet); any other not-ready shard is behind by `lagging_tasks`. ## Why? When a handover stalls, the only signal today is `Wait handover not ready`, which reports counts plus the single worst shard, once a second for the life of the wait. That is not enough to name the shards actually holding it up, or to tell a shard that never took a watermark from one whose watermark is not being acked. These events make both attributable, and the summary form costs one row per failed handover instead of one log line per second. Emission is a no-op unless a `LoggerProvider` is configured, so there is no cost for deployments that have not opted in. ## How did you test it? - [x] covered by new unit tests - [x] built New tests pin the behavior that keeps these off the hot path: - `TestHandoverWatermarkRemovedOnlyWhenTracked` — the per-notification branch emits nothing when there is no watermark to remove. - `TestHandoverWatermarkEvents` — set/update/remove, and that a repeat notification at the same version emits nothing. - `TestHandoverWatermarkPendingThenResolved` — the unacquired-shard sentinel is reported as `pending`, and resolving it on acquire emits nothing. - `TestEmitHandoverLagSummarySilentWhenReady` — a completed handover emits nothing. - `TestCheckHandoverOnceSnapshotIsLastPollOnly` — the snapshot is overwritten per poll, so laggards from an earlier poll cannot leak into the summary. - `TestEmitHandoverLagSummaryNamesLaggingShards` / `ExitReason` / `Truncates` — payload contents, exit-reason classification, and the per-shard cap. `go test ./service/history/shard/... ./service/worker/migration/...` passes; `go vet` and `gofmt` clean.", "url": "https://github.com/temporalio/temporal/pull/11401", "createdAt": "2026-08-03T15:01:23Z", "updatedAt": "2026-08-13T02:00:50Z", "timestamp": "2026-08-13T02:00:50Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation", "reliability-2026" ], "author": "michaely520", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:841fc9fec0b64fc24cd2", "signalId": "github:temporalio/temporal:pull_request:11422", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11422", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Skip unbuildable replication tasks on stream sender instead of blocking", "text": "## What changed? Skip unbuildable replication tasks on stream sender instead of blocking the stream. The skip is logged and new metric ReplicationTaskSendSkipped added. ## Why? When the replication stream sender cannot build (\"convert\") a task, it retries and, once the retry budget is exhausted, returns an error that tears the stream down. On reconnect the sender resumes from the same watermark, hits the same unbuildable task, and blocks the whole shard's stream indefinitely. This change skips the task to unblock and logs, add a metric for the skipped task so that it could be investigated later. ## How did you test it? - [x] built - [x] run locally and tested manually - [ ] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s)", "url": "https://github.com/temporalio/temporal/pull/11422", "createdAt": "2026-08-05T15:53:14Z", "updatedAt": "2026-08-13T01:41:55Z", "timestamp": "2026-08-13T01:41:55Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation", "reliability-2026" ], "author": "qyc5937", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:1d2f4770a19d8fa7f557", "signalId": "github:temporalio/temporal:pull_request:10200", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:10200", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Validator generator [WiP]", "text": "## What changed? Opt-in validator that exhaustively validate all protobuf fields in 1 place. ## Why? Adds semantic validation for protobufs as a thin layer before the proto request reaches actual business logic. ## How did you test it? - [ ] built - [ ] run locally and tested manually - [ ] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s)", "url": "https://github.com/temporalio/temporal/pull/10200", "createdAt": "2026-05-08T01:12:05Z", "updatedAt": "2026-08-13T01:34:50Z", "timestamp": "2026-08-13T01:34:50Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:75b56e892a729b8c7b9b", "signalId": "github:temporalio/temporal:pull_request:11526", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11526", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Fix flakereport incomplete JUnit failures", "url": "https://github.com/temporalio/temporal/pull/11526", "createdAt": "2026-08-13T01:11:18Z", "updatedAt": "2026-08-13T01:11:18Z", "timestamp": "2026-08-13T01:11:18Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:28d6e50c2f1f132c9641", "signalId": "github:temporalio/temporal:pull_request:11439", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11439", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Detect incompatible metric schemas in mixed-brain tests", "text": "## What changed? - Give the current and previous-release mixed-brain servers separate Prometheus endpoints. - Scrape both endpoints after the OMES workload and fail on inconsistent label sets within either server or incompatible label sets across versions. - Require `task_requests` coverage and narrowly allowlist label additions that already exist between the current and previous release. - Add focused unit coverage for incompatible, internally inconsistent, compatible, and allowlisted schemas. ## Why? A metric whose label count changes across mixed server versions can be rejected by the Cloud metrics handler, dropping that metric and potentially hiding alerts. Running this check in the existing Temporal PR mixed-brain test catches those compatibility regressions before merge. ## How did you test it? - [ ] built - [x] run locally and tested manually - [ ] covered by existing tests - [x] added new unit test(s) - [x] added new functional test(s) `go test -tags test_dep . -run '^TestMetricSchemaProblems' -count=1` `MIXED_BRAIN_TEST_DURATION=30s PERSISTENCE_DRIVER=postgres12 TEST_OUTPUT_ROOT=/tmp/temporal-mixedbrain-metric-schema-clean go test -tags test_dep . -run '^TestMixedBrain$' -count=1 -timeout 15m -v` The end-to-end run passed against the current source and previous release tag `v1.31.2`. ## Potential risks The scan covers metric series emitted by the OMES workload; metrics not exercised during the run are not compared. The metric-specific allowlist accepts only the exact known one-label additions and may need deliberate maintenance as old compatibility exceptions age out. Lint was not run.", "url": "https://github.com/temporalio/temporal/pull/11439", "createdAt": "2026-08-06T16:24:40Z", "updatedAt": "2026-08-13T00:43:53Z", "timestamp": "2026-08-13T00:43:53Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "chaptersix", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:fdcbdf80d4d025ea90b1", "signalId": "github:temporalio/temporal:pull_request:11522", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11522", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add flaky test report input artifact", "text": "## What changed? - Add a fan-in job to the test workflow after unit, integration, and functional tests. - Download the current attempt's per-job JUnit artifacts and upload them as one `flaky-report-input----` artifact. - Include the fan-in job in the aggregate test status. This PR only produces the rollup artifact; it does not change the flaky-report consumer yet. ## Why? Give the flaky-test reporting workflow one artifact per CI run to download instead of discovering and downloading every job artifact independently. ## 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) Validated the workflow with Ruby's YAML parser and `git diff --check`. ## Potential risks The aggregate test status now fails if the fan-in job cannot find or upload JUnit reports. The rollup artifact retains the existing reports for 28 days, adding artifact storage until the consumer migrates.", "url": "https://github.com/temporalio/temporal/pull/11522", "createdAt": "2026-08-13T00:14:52Z", "updatedAt": "2026-08-13T00:32:59Z", "timestamp": "2026-08-13T00:32:59Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "chaptersix", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:a9972518e59480843546", "signalId": "github:temporalio/temporal:pull_request:11464", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11464", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "NEXUS-504: Refactor Nexus frontend interceptors", "text": "## What changed? Refactoring Nexus frontend interceptors ## Why? https://temporalio.atlassian.net/browse/NEXUS-504 ## How did you test it? - [x] built - [x] run locally and tested manually - [x] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) ## Potential risks - [ ] Medium risk of regression, will be covered through tests", "url": "https://github.com/temporalio/temporal/pull/11464", "createdAt": "2026-08-11T00:50:02Z", "updatedAt": "2026-08-12T23:37:44Z", "timestamp": "2026-08-12T23:37:44Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "mavemuri", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:a05441c3cac3b3b4d242", "signalId": "github:temporalio/temporal:pull_request:11520", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11520", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Populate CallbackInfo.outcome", "text": "⚠️ This is part of a stacked PR set, to be merged into `chrsmith/wc-add-worker-cb-variant`. This will not go directly into `main`. This was originally sent out as https://github.com/temporalio/temporal/pull/11413, which also persisted the terminal failure of CHASM Callback components. This new version does not do that, and instead just includes the various refactorings and cleanups. --- ## What changed? The [worker callbacks API changes](https://github.com/temporalio/api/compare/feature/worker-callbacks?expand=1) adds the result of a Callback invocation to the `CallbackInfo` object. This PR wires it through for the Describe- response for Standalone Activities. (We already have tests that the completion callbacks were triggered for standalone activities, we now just verify the `CallbackInfo`'s returned have the right `outcome` data as well.) As part of this, various refactorings were applied to consolidate the conversion logic for `callback.Callback` and other types. (e.g. getting the API Status enum value, or the `commonpb.Callback` proto.) ## Why? This wiring and the associated refactorings are all part of adding worker callbacks, and making that easier to land. (Worker callbacks will need to wire the `CallbackInfo` objects to the Describe- endpoint, covered in a subsequent PR.) ## How did you test it? - [x] built - [x] run locally and tested manually - [x] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) ## Potential risks None that I can think of.", "url": "https://github.com/temporalio/temporal/pull/11520", "createdAt": "2026-08-12T22:33:50Z", "updatedAt": "2026-08-12T23:09:33Z", "timestamp": "2026-08-12T23:09:33Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "chrsmith", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:9d5b4c352ff9dcfcf6f9", "signalId": "github:temporalio/temporal:pull_request:11415", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11415", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add completion callbacks to SANOs", "text": "⚠️ This is part of a stacked PR set, to be merged into `chrsmith/wc-persist-callback-terminal-failures`. This will not go directly into `main`, until the overall feature is code complete. --- ## What changed? The API surface area for the worker callbacks feature adds a new `completion_callbacks` field to SANOs, allowing users to register callbacks to be executed when the SANO completes. (Just like standalone Activities.) This PR implements that feature for SANO, allowing completion callbacks to be added, executed, and for their status to be reported by the `DescribeNexusOperationExecution` endpoint. However, this new capability is guarded by a per-namespace dynamic config value `\"nexusoperation.enableNexusCallbacks\"`. Attempts to attach worker callbacks to SANO will fail, and namespaces will need to opt-into using this new feature. ## Why? This is part of the overall worker callbacks feature. (With worker callbacks being a specific kind of completion callback you can attach to SANO.) Worker-variant callbacks are still not supported in this PR. Only Nexus- and Internal- variant callbacks will be accepted, if the feature is enabled. ## 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 - It's essentially a new feature, and so there are lots of edge cases we need to consider. For example, that repeated calls to `Start-` are idempotent. That the `on_conflict_options` are honored, etc. Otherwise, we run the risk of SANO being slightly inconsistent with how completion callbacks work for standalone Activities. > I added a comment to call out a minor bug in standalone Activities. It's already on the ACT team's radar. On the [SAA bugs punch list](https://app.notion.com/p/temporalio/SAA-bug-claims-3a08fc5677388009a690cff570aeaa45?source=copy_link). > \"FT C9. On-conflict callback attachment is not idempotent or atomic\"", "url": "https://github.com/temporalio/temporal/pull/11415", "createdAt": "2026-08-04T17:28:53Z", "updatedAt": "2026-08-12T22:54:47Z", "timestamp": "2026-08-12T22:54:47Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "chrsmith", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:f824726fd9bf4f93d7d4", "signalId": "github:temporalio/temporal:pull_request:10417", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:10417", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Adaptive test timeouts via Await", "text": "## What changed? Adds `testcontext.EnsureRemaining` and has `await` use it so long await calls can request additional test-scoped context time while still respecting the test context cap. ## Why? Await calls can need more time than the default test context has left (esp after the environment setup). Extending the test timeout in this way allows for (1) stuck tests to fail earlier than the default test timeout and (2) legitimately longer running tests to pass without manually tweaking the test timeout.", "url": "https://github.com/temporalio/temporal/pull/10417", "createdAt": "2026-05-28T22:24:57Z", "updatedAt": "2026-08-12T22:54:05Z", "timestamp": "2026-08-12T22:54:05Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:4e17b52f6d6091eddc97", "signalId": "github:temporalio/temporal:pull_request:10781", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:10781", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Richer await timeout diagnostics", "text": "## What changed? Stacks on #10417. Adds clearer timeout diagnostics for await failures and test context cleanup after the core context-extension behavior is in place. The report now includes aligned detail rows, attempt duration summaries, attempt timeout counts, deadline-limit causes, and context extension summaries when available. The await reporting tests now exercise the public behavior directly instead of unit-testing the report helper.", "url": "https://github.com/temporalio/temporal/pull/10781", "createdAt": "2026-06-19T21:44:32Z", "updatedAt": "2026-08-12T22:50:31Z", "timestamp": "2026-08-12T22:50:31Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:c0dca8bb70bac425776e", "signalId": "github:temporalio/temporal:pull_request:10377", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:10377", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Await 2.0", "text": "## 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? - [ ] built - [ ] run locally and tested manually - [ ] covered by existing tests - [ ] added new unit test(s) - [ ] added new functional test(s) ## Potential risks _Any change is risky. Identify all risks you are aware of. If none, remove this section._", "url": "https://github.com/temporalio/temporal/pull/10377", "createdAt": "2026-05-24T20:05:59Z", "updatedAt": "2026-08-12T22:50:31Z", "timestamp": "2026-08-12T22:50:31Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:8d9d2488e08d9b93867e", "signalId": "github:temporalio/temporal:pull_request:11456", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11456", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add support for worker-variant callbacks", "text": "## What changed? This PR updates the CHASM `Callback` component to support the new `Worker`-variant. Unlike `Nexus` callbacks, which just issue an HTTP `POST` request to deliver a Nexus completion result (and potentially in another namespace), these new `Worker` callbacks are for invoking a Nexus operation within the same namespace. This PR does _not_ enable Worker callbacks anywhere. It just adds the underlying capability. (The next PR in the stack will allow you to enable worker callbacks for SANOs.) ## Why? This is the actual support for the worker callbacks feature, enabling the end-to-end scenario. Worker callbacks as a capability will make it easier to implement so-called Nexus Connectors, where you expose a Nexus service from a non-Nexus protocol. (e.g. having a REST HTTP server act as a gateway for Nexus operations.) ## How did you test it? - [x] built - [x] run locally and tested manually - [x] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) ## Potential risks 🤔", "url": "https://github.com/temporalio/temporal/pull/11456", "createdAt": "2026-08-10T16:59:54Z", "updatedAt": "2026-08-12T22:44:52Z", "timestamp": "2026-08-12T22:44:52Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "chrsmith", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:75ff1c7729c50b1fc7a2", "signalId": "github:temporalio/temporal:pull_request:11512", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11512", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Use generic JUnit documents at runner boundaries", "text": "Moves the testrunner's report input and output boundaries onto `tools/common/junit.Testsuites`. The existing retry merger remains unchanged behind that seam, so this is a behavior-preserving preparation for canonical attempt rendering. Stack: depends on #11513. The canonical attempt-results PR follows this one.", "url": "https://github.com/temporalio/temporal/pull/11512", "createdAt": "2026-08-12T22:00:08Z", "updatedAt": "2026-08-12T22:43:00Z", "timestamp": "2026-08-12T22:43:00Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:40f4b241ca167bcdf718", "signalId": "github:temporalio/temporal:pull_request:11513", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11513", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Harden shared JUnit report IO", "text": "Strengthens the shared JUnit module's I/O contract. Reads reject trailing XML and include the source path in errors, while writes atomically replace the destination so interrupted writes cannot corrupt an existing report. It also exposes counter validation for canonical report renderers without imposing that invariant on legacy producers yet. Stack: depends on #11480. The testrunner boundary cleanup follows this one.", "url": "https://github.com/temporalio/temporal/pull/11513", "createdAt": "2026-08-12T22:05:45Z", "updatedAt": "2026-08-12T22:42:51Z", "timestamp": "2026-08-12T22:42:51Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:00ef828d76c8e0012f94", "signalId": "github:temporalio/temporal:pull_request:11500", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11500", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Enable Claude reviews for OSS Matching", "text": "## Summary - Enable automated Claude PR reviews for members of `temporalio/oss-matching`. ## Impact Members of the OSS Matching team will receive automated Claude reviews after the workflow's existing organization membership, repository permission, and label checks pass. ## Validation - `git diff --check` - Confirmed the branch contains a single workflow-only commit based on the latest `origin/main`. --- > [!NOTE] > **Low Risk** > Single workflow env change; no application or security logic is modified, only which GitHub team triggers an existing gated review job. > > **Overview** > Extends automated Claude PR reviews to **`temporalio/oss-matching`** by adding `oss-matching` to the `REVIEW_TEAMS` list in `.github/workflows/claude-review-teams.yml` (alongside existing `nexus` and `act`). > > PRs from active members of that team still go through the same eligibility path as other configured teams: org membership, repo write access, and no `skip-claude-review` label. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 86e1e13fd74a1afd781e690288d93e1a4e770956. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot). ", "url": "https://github.com/temporalio/temporal/pull/11500", "createdAt": "2026-08-12T13:32:52Z", "updatedAt": "2026-08-12T22:00:45Z", "timestamp": "2026-08-12T22:00:45Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "Shivs11", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:75a322dbb1c1eafd6e8f", "signalId": "github:temporalio/temporal:pull_request:11511", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11511", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Preserve UTF-8 in test summaries", "text": "Test summary details are truncated to byte budgets before being written to Markdown and JSON. Ensure the retained head and tail start at UTF-8 rune boundaries so multibyte failure output remains valid after truncation. The regression test uses multibyte input whose previous tail boundary split a rune.", "url": "https://github.com/temporalio/temporal/pull/11511", "createdAt": "2026-08-12T21:57:45Z", "updatedAt": "2026-08-12T21:57:45Z", "timestamp": "2026-08-12T21:57:45Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:8b11f49c2d83bf8d73c3", "signalId": "github:temporalio/temporal:pull_request:11413", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11413", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Persist Callback terminal failures", "text": "⚠️ This is part of a stacked PR set, to be merged into `chrsmith/wc-add-worker-cb-variant`. This will not go directly into `main`. --- ## What changed? Add a new field to the CHASM Callback component to persist the terminal failure of a CHASM Callback. The [CallbackState](https://github.com/temporalio/temporal/blob/main/chasm/lib/callback/proto/v1/message.proto#L11) that includes a `last_attempt_failure` field which is set whenever there is a delivery error. This would contain the terminal failure for the CHASM callback as long as the _only_ way the callback could fail is due to a non-retryable delivery. (And not a cancellation, timeout, etc.) We now have a separate `TerminalFailure` field, stored separately than the `last_attempt_failure`. (This is to avoid growing the size of the persisted `CallbackState` proto, as well as reducing the size of database writes since the `TerminalFailure` will only be written once.) ## Why? Currently, there is no need for this field. Because it is not possible to cancel a CHASM Callback, or for it to timeout, the terminal failure can be _inferred_ by referencing the `last_attempt_failure`. However, we will want CHASM Callbacks to support \"external\" failures. If not for the worker callbacks feature, then for manual completions down the road. Also, it avoids any confusion or ambiguity about whether `last_attempt_failure` is the _terminal_ failure, or just the last (retryable) delivery error. ## How did you test it? - [x] built - [x] run locally and tested manually - [x] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) ## Potential risks - Adding a new CHASM field can be tricky, because when loading existing CHASM components the field may-or-may-not be present. In this case, we fall back to `last_attempt_failure` if `TerminalFailure` is not present, which is sufficient. - If a CHASM component is persisted with the new `TerminalFailure` field, and then the server is _downgraded_, the next write for the CHASM component will _delete_ the \"unknown\" `TerminalFailure` field. Because of the fallback to `last_attempt_failure`, this too is accounted for.", "url": "https://github.com/temporalio/temporal/pull/11413", "createdAt": "2026-08-04T17:20:01Z", "updatedAt": "2026-08-12T21:50:24Z", "timestamp": "2026-08-12T21:50:24Z", "metrics": { "reactions": 0, "comments": 9 }, "labels": [], "author": "chrsmith", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:a77ee5a87731ae51e37f", "signalId": "github:temporalio/temporal:pull_request:11505", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11505", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Track process-lifetime object leak baselines", "text": "## What changed? Add process-lifetime baselines to `objectleak`, ignore tiny pointer-free allocations that the runtime cannot track individually, and allow asynchronous cleanup the full settle timeout. ## Why? Make object leak reports actionable by distinguishing process-lifetime objects from leaks and avoiding runtime-induced false positives. Replaces #11313.", "url": "https://github.com/temporalio/temporal/pull/11505", "createdAt": "2026-08-12T16:47:47Z", "updatedAt": "2026-08-12T21:21:41Z", "timestamp": "2026-08-12T21:21:41Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:c97def4dde0345bbfd31", "signalId": "github:temporalio/temporal:pull_request:11481", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11481", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Skip worker commands task queues in missing TQ check", "text": "## What Skip worker commands task queues (`temporal-sys/worker-commands/...`) when checking for missing task queues during version promotion (SetCurrent / SetRamping). ## Why An SDK bug caused version attributes to be set on worker commands queues, registering them in a deployment version. These queues are ephemeral and don't support versioning, so `IsVersionMissingTaskQueues` would incorrectly flag them as missing and block version promotion. ## How did you test it? Unit tests for `checkForMissingTaskQueues`: - Worker commands TQ in prev version is excluded from missing list - User TQ missing from new version is still reported - All TQs present returns empty", "url": "https://github.com/temporalio/temporal/pull/11481", "createdAt": "2026-08-11T22:22:30Z", "updatedAt": "2026-08-12T21:13:09Z", "timestamp": "2026-08-12T21:13:09Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "rkannan82", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:64a42b67d470b54d2d47", "signalId": "github:temporalio/temporal:pull_request:11450", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11450", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Enable host level events cache by default", "text": "## What changed? Flip the default of `history.enableHostLevelEventsCache` from `false` to `true`, so history shards share a single host-level events cache instead of each allocating a shard-level one. ## Why? We have been using host level history cache for a while. We can now enable it in code by default. ## How did you test it? - [x] built - [x] covered by existing tests", "url": "https://github.com/temporalio/temporal/pull/11450", "createdAt": "2026-08-09T03:52:24Z", "updatedAt": "2026-08-12T20:38:23Z", "timestamp": "2026-08-12T20:38:23Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "reliability-2026" ], "author": "prathyushpv", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:86325ec3d937dcbe1621", "signalId": "github:temporalio/temporal:pull_request:11169", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11169", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "[CHASM] Support WithRequestID on UpdateComponent", "text": "## What changed? - `WithRequestID` now applies to `UpdateComponent`, enabling execution-level idempotency guarding via request ID. - When a request ID is passed as part of an `UpdateComponent` call (via API handler), it is persisted upon successful updateFn call. If it is already present, instead, `UpdateComponent` fails with a `FailedPrecondition`. - When a request ID is not passed in, a generated ID is still created for error tracing purposes, but it is not written to mutable state. - On transaction close, mutable state will sweep the oldest RequestIDs (with an `attach_time`) upon hitting the configured limit. - This will sweep both entries below a configurable max age, as well as past a certain hard length limit. ## Why? - Scheduler's `UpdateSchedule` and `PatchSchedule` are implemented as handlers that persist a signal in V1. V1 signals provide idempotency via their request IDs. Scheduler V2 doesn't make use of signals, so instead, it must record request IDs explicitly. - We reuse the existing map within mutable state. - We *must* fail with an explicit error (`FailedPrecondition`) instead of simply returning a zero value (as Signals would on repeated successful requests). This is because `UpdateComponent` can apply to API models that include response values (which we don't record, therefore, we can't return on subsequent calls). ## How did you test it? - [ ] built - [ ] run locally and tested manually - [ ] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s)", "url": "https://github.com/temporalio/temporal/pull/11169", "createdAt": "2026-07-21T00:51:10Z", "updatedAt": "2026-08-12T20:27:04Z", "timestamp": "2026-08-12T20:27:04Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "lina-temporal", "state": "open", "assignees": [ "fretz12" ], "change": "updated" } }, { "id": "event:dd1feda3751e476aa529", "signalId": "github:temporalio/temporal:pull_request:11492", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11492", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Stuartwells/gradual connect shedding tasks", "text": "## What changed? Adding support for a gradual connection period for globalized namespaces. This determines the start, step, and duration for ramp-up, during which a diminishing percentage of replication traffic will be shed (to be filled in via manual force-replicate at the end). ## Why? There are currently issues with clusters becoming overloaded during large migrations and potentially large globalizes. By ramping up the traffic, that gives more time for resources on the target cluster to scale up. ## 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) ## Potential risks This change drops tasks from the passive and intentionally engages a recovery mechanism. Potential gap I am testing against the most is ensuring the tasks are eventually propagated to the passive and not lost in the process. Force-replicate also needs to be manually initiated, so this leaves an opportunity for a gap if that is forgotten.", "url": "https://github.com/temporalio/temporal/pull/11492", "createdAt": "2026-08-12T01:20:47Z", "updatedAt": "2026-08-12T20:18:07Z", "timestamp": "2026-08-12T20:18:07Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stuart-wells", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:1240f3c48bd61970c6c4", "signalId": "github:temporalio/temporal:pull_request:11510", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11510", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Reduce worker deployment log spam", "text": "Remove temporary worker deployment workflow logs to reduce log spam. Checks: `go test -tags test_dep ./service/worker/workerdeployment`; `make lint-code`. --- > [!NOTE] > **Low Risk** > Logging-only deletion with no control-flow or state changes in the deployment workflow. > > **Overview** > Removes temporary **Info**-level debug logging from the worker deployment workflow in `workflow.go` to cut log volume in steady state and during continue-as-new. > > Deleted log sites include workflow startup (raw state dump), run start, continue-as-new eligibility, the continue-as-new transition itself, **SetCurrent** update entry, and **updateMemo**—each previously tagged for removal. Workflow logic, metrics, and existing error/info paths are unchanged. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 17d70832a604132536bec962e4203cd6fc1d087f. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot). ", "url": "https://github.com/temporalio/temporal/pull/11510", "createdAt": "2026-08-12T19:28:00Z", "updatedAt": "2026-08-12T19:57:21Z", "timestamp": "2026-08-12T19:57:21Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "carlydf", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:c485aa7f270a9525c2e9", "signalId": "github:temporalio/temporal:pull_request:11506", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11506", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Reuse one persistence factory during server initialization", "text": "## What changed? Reuse a single persistence factory during server initialization and expose it to the root Fx graph as `BootstrapPersistenceFactory`. The named interface encodes the startup-only lifecycle without tags, bridges, or adapters. The factory is closed exactly once after startup, on failed construction, or during `Stop` when the server was never started. Callers are now explicitly documented as responsible for calling `Stop`. Companion SaaS change: temporalio/saas-temporal#8369. ## Why? Server initialization previously constructed and closed a separate persistence factory for each bootstrap operation. One explicitly owned bootstrap factory avoids premature closes, makes cleanup deterministic, and helps #11458 by ensuring uninterrupted ownership of the SQLite database. ## Testing - `go test -count=1 ./temporal -run ^TestNewServer$` - `go test -count=1 -run ^$ ./temporal ./tests/testcore` - `go vet ./temporal ./tests/testcore` The full `./temporal` run reached the existing flaky `TestNewServerWithOTEL` span assertion; the targeted server lifecycle test passed.", "url": "https://github.com/temporalio/temporal/pull/11506", "createdAt": "2026-08-12T16:47:49Z", "updatedAt": "2026-08-12T19:56:04Z", "timestamp": "2026-08-12T19:56:04Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:909a772f8f77420f916c", "signalId": "github:temporalio/temporal:pull_request:10129", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:10129", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Reduce test runner resources", "text": "## What changed? Only use 4-core ARM runners instead of 8-core; and increase shard size for test sharding. ## Why? 8-core runners have - at least during peak hours - very long provisioning time (several minutes). By using 4-core we reduce that time, but risk OOM kills as they have less memory. To counter that, we increase the number of test shards so that fewer tests are run per shard. ## How did you test it? TBD", "url": "https://github.com/temporalio/temporal/pull/10129", "createdAt": "2026-04-30T01:04:58Z", "updatedAt": "2026-08-12T18:32:09Z", "timestamp": "2026-08-12T18:32:09Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "test-all-dbs" ], "author": "stephanos", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:51ca909ec85154573530", "signalId": "github:temporalio/temporal:pull_request:11446", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11446", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Reorganize CHASM activity codebase", "text": "## What changed? - Reorganize `chasm/lib/activity` ## Why? - Improve navigability and codebase comprehensibility ## How did you test it? - [x] covered by existing tests", "url": "https://github.com/temporalio/temporal/pull/11446", "createdAt": "2026-08-07T18:22:04Z", "updatedAt": "2026-08-12T18:25:53Z", "timestamp": "2026-08-12T18:25:53Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "dandavison", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:74d3d557af49d087fef5", "signalId": "github:temporalio/temporal:pull_request:11509", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11509", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "run admin batch in temporal-system", "text": "## What changed? 1. updated batch administration operations to run in the system namespace while continuing to use per-namespace task queues and workers. 2. allow batch activities running in the system namespace operating on other target namespaces 3. add ns to jobID and print all previous changes in tdbg prompts ## Why? to run refresh tasks in passive clusters of user global namespaces ## 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 refer to validation of the security for cross ns operation", "url": "https://github.com/temporalio/temporal/pull/11509", "createdAt": "2026-08-12T18:15:28Z", "updatedAt": "2026-08-12T18:16:06Z", "timestamp": "2026-08-12T18:16:06Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "feiyang3cat", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:3403c281b0c00a81b4c5", "signalId": "github:temporalio/temporal:pull_request:11494", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11494", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "move admin batch jobs to sys ns", "text": "## What changed? - updated batch administration operations to run in the system namespace while continuing to use per-namespace task queues and workers. - allow batch activities running in the system namespace operating on other target namespaces - add ns to jobID and print all previous changes in tdbg prompts ## Why? to run refresh tasks in passive clusters of user global namespaces ## 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 need solid validation of the security for cross ns operation refer to analysis of this feature", "url": "https://github.com/temporalio/temporal/pull/11494", "createdAt": "2026-08-12T05:27:11Z", "updatedAt": "2026-08-12T18:12:37Z", "timestamp": "2026-08-12T18:12:37Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "feiyang3cat", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:85c44305fe707d4078b2", "signalId": "github:temporalio/temporal:pull_request:11211", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11211", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add data race summary to CI report", "text": "## What changed? Add data race summary to CI report ## Why? Notify when CI detects data race issues in main. ## How did you test it? - [X] built - [X] run locally and tested manually - [X] covered by existing tests - [X] added new unit test(s) - [ ] added new functional test(s)", "url": "https://github.com/temporalio/temporal/pull/11211", "createdAt": "2026-07-22T15:56:04Z", "updatedAt": "2026-08-12T18:06:31Z", "timestamp": "2026-08-12T18:06:31Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "awln-temporal", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:733944f6be374fe82a7b", "signalId": "github:temporalio/temporal:pull_request:11380", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11380", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Recognize the new `commonpb` Worker callback variant", "text": "⚠️ This is part of a stacked PR set, to be merged into `feature/worker-callbacks`. This will not go directly into `main`, until the overall feature is code complete. --- ## What changed? The worker callbacks feature introduces a new variant of `commonpb.Callback` to describe callbacks for invoking a Nexus operation on a waiting worker. This PR adds the support for recognizing this new kind of callback in the CHASM code, but does not implement any sort of support. (Supplying a worker callback to a standalone Activity or workflow will result in an error.) ## Why? Part of the overall worker callbacks feature. ## How did you test it? - [x] built - [x] run locally and tested manually - [x] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s) ## Potential risks Nothing I can think of.", "url": "https://github.com/temporalio/temporal/pull/11380", "createdAt": "2026-07-31T20:25:45Z", "updatedAt": "2026-08-12T17:03:50Z", "timestamp": "2026-08-12T17:03:50Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "chrsmith", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:7799763c3759afe041fb", "signalId": "github:temporalio/temporal:pull_request:11508", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11508", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Eliminate expected object leak suppressions", "text": "## What changed? - Unregister process-global gRPC resolver and OpenTelemetry logger state during lifecycle shutdown. - Close the test matching client RPC factory and clear removed test references. - Remove every `WithExpected` entry from `objectLeakOpts`. ## Why? The leak test was suppressing the cluster graph instead of enforcing that cluster-owned objects become collectible. These lifecycle fixes leave only the protobuf traversal prune. ## Testing - `go test -count=1 -tags test_dep ./common/membership -run 'TestGRPCResolver'` - `go test -count=1 ./temporal` - `go test -count=1 ./tests/testcore -run 'TestSharedClusterT_RemoveTestReleasesTest'` - `go test -count=1 ./tests/leakcheck -run '^$'` Replaces #11503.", "url": "https://github.com/temporalio/temporal/pull/11508", "createdAt": "2026-08-12T16:47:54Z", "updatedAt": "2026-08-12T16:47:54Z", "timestamp": "2026-08-12T16:47:54Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:7260d6b7ea710dda85f8", "signalId": "github:temporalio/temporal:pull_request:11507", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11507", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Close SQLite databases with their owners", "text": "## What changed? Properly close SQLite connections and databases. ## Why? SQLite previously retained one shared connection pool per DSN for the entire process. Each SQL factory now owns an initial reference while its stores borrow additional references. Closing the final factory releases the connection pool without losing an in-memory database when shorter-lived stores close. Replaces #11458.", "url": "https://github.com/temporalio/temporal/pull/11507", "createdAt": "2026-08-12T16:47:52Z", "updatedAt": "2026-08-12T16:47:52Z", "timestamp": "2026-08-12T16:47:52Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:dd74e10293c72b251911", "signalId": "github:temporalio/temporal:pull_request:11483", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11483", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Reuse one persistence factory during server initialization", "text": "## What changed? Reuse a single persistence factory during server initialization. ## Why? Server initialization previously constructed and closed a separate persistence factory for each bootstrap operation. This also helps with https://github.com/temporalio/temporal/pull/11458 as this change ensures there's uninterrupted ownership of the sqlite database.", "url": "https://github.com/temporalio/temporal/pull/11483", "createdAt": "2026-08-11T22:45:49Z", "updatedAt": "2026-08-12T16:39:57Z", "timestamp": "2026-08-12T16:39:57Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "stephanos", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:a0f1d0d98166dfbb4949", "signalId": "github:temporalio/temporal:pull_request:11313", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11313", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Track process-lifetime object leak baselines", "text": "## What changed? The `objectleak` package has no support for establishing a baseline; therefore it erroneously reports false positives. ## Why? Ensure `objectleak` report is actionable and insightful.", "url": "https://github.com/temporalio/temporal/pull/11313", "createdAt": "2026-07-27T18:52:47Z", "updatedAt": "2026-08-12T16:39:57Z", "timestamp": "2026-08-12T16:39:57Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "stephanos", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:0199d3cab0e8f3ef353f", "signalId": "github:temporalio/temporal:pull_request:11503", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11503", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Eliminate expected object leak suppressions", "text": "## What changed? - unregister process-global gRPC resolver and OpenTelemetry logger state during lifecycle shutdown - close the test matching client RPC factory and clear removed test references - let object checks wait for asynchronous shutdown cleanup while avoiding tiny-allocation false positives - remove every `WithExpected` entry from `objectLeakOpts` ## Why The leak test was suppressing the cluster graph instead of enforcing that cluster-owned objects become collectible. These lifecycle fixes leave only the process-lifetime baseline and the protobuf traversal prune. Stacked on #11458. The stack also includes #11483 and #11313. ## Testing - `make leak-test` (15 measured clusters: 0 expected, 0 unexpected retained objects) - focused tests for `common/testing/objectleak`, `common/membership`, `temporal`, and `tests/testcore` - `make lint`", "url": "https://github.com/temporalio/temporal/pull/11503", "createdAt": "2026-08-12T16:09:27Z", "updatedAt": "2026-08-12T16:39:56Z", "timestamp": "2026-08-12T16:39:56Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:51099c71c55a0191bcff", "signalId": "github:temporalio/temporal:pull_request:11458", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11458", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Close SQLite databases with their owners", "text": "## What changed? Properly close SQLite connection and database. ## Why SQLite previously retained one shared connection pool per DSN for the entire process. Each SQL factory now owns an initial reference while its stores borrow additional references. Closing the final factory releases the connection pool without losing an in-memory database when shorter-lived stores close.", "url": "https://github.com/temporalio/temporal/pull/11458", "createdAt": "2026-08-10T20:53:04Z", "updatedAt": "2026-08-12T16:39:56Z", "timestamp": "2026-08-12T16:39:56Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:b961f8e2aa225e8bda25", "signalId": "github:temporalio/temporal:pull_request:11502", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11502", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Use chasm context NamespaceEntry instead of injecting namespace registry for activity code", "text": "## What changed? Updated the activity code to use a CHASM context API that was added after the original code was written. ## Why? Prevent this pattern from being copied to other libraries.", "url": "https://github.com/temporalio/temporal/pull/11502", "createdAt": "2026-08-12T15:38:14Z", "updatedAt": "2026-08-12T16:22:10Z", "timestamp": "2026-08-12T16:22:10Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "reliability-2026" ], "author": "bergundy", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:fd85d4af71797bd2adfc", "signalId": "github:temporalio/temporal:issue:2341", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:issue:2341", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "config: strict mode for configuration parsing", "text": "**Is your feature request related to a problem? Please describe.** My team is working on a new deployment of Temporal and we recently spent an entire day debugging an issue related to a missing key in configuration due to lack of error messaging and validation by the bootstrap code. Example: ``` metrics: hostPort: \"127.0.0.1:8125\" prefix: \"temporal\" ``` needed to be ``` metrics: statsd: hostPort: \"127.0.0.1:8125\" prefix: \"temporal\" ``` The server started up fine, the logic to configure the [bootstrap code looked for any of the custom configured reporters](https://github.com/temporalio/temporal/blob/e153684480968b9b271574b589abaedd5525a255/common/metrics/config.go#L260-L271), didn't find any, and everything booted as normal, only we were not getting any stats. **Describe the solution you'd like** I would like the option for strict config validation. If a key is unrecognized, the server should fail to start so it can be corrected. I'm happy to put together a PR for option 1 below if someone can give their thoughts and approval on the approach. **Describe alternatives you've considered** - **Option 1** Change YAML unmarshaling to reject unknown fields (see [yaml.Decoder.KnownFields](https://pkg.go.dev/gopkg.in/yaml.v3#Decoder.KnownFields)), and ideally expand the use of the `gopkg.in/validator.v2` throughout the config structs. Could we move to this as a default? If not add a flag which the server supports to unmarshal the config in strict mode. - **Option 2** Move to protobuf for configuration specifications. This would have the benefit of centralizing config specifications in a single place and definition language rather than scattering structs throughout the code base. I previously made this suggestion in a [`#development Slack thread](https://temporalio.slack.com/archives/CTQU95E84/p1639591413096200): > Has the team considered moving to protobuf for the config schema? discovery and validation are subpar with how it's all done with structs currently. Example from our project [lyft/clutch](github.com/lyft/clutch) which uses proto for defining config and uses [envoyproxy/protoc-gen-validate](https://github.com/envoyproxy/protoc-gen-validate) for validation: > - Config definition: [api/config/gateway/v1/gateway.proto](https://github.com/lyft/clutch/blob/43aa67e73d776f3d232ea5d1188f01e194c50b63/api/config/gateway/v1/gateway.proto). > - Example YAML conforming to definition: [clutch-config.yaml](https://github.com/lyft/clutch/blob/43aa67e73d776f3d232ea5d1188f01e194c50b63/backend/clutch-config.yaml) > - Example output from a bad config: `{\"level\":\"fatal\",\"ts\":1641326218.3299987,\"caller\":\"gateway/config.go:71\",\"msg\":\"configuration proto validation failed\",\"file\":\"clutch-config.yaml\",\"error\":\"invalid Config.Gateway: embedded message failed validation | caused by: invalid GatewayOptions.Listener: value is required\"}`", "url": "https://github.com/temporalio/temporal/issues/2341", "createdAt": "2022-01-04T20:12:59Z", "updatedAt": "2026-08-12T16:09:47Z", "timestamp": "2026-08-12T16:09:47Z", "metrics": { "reactions": 1, "comments": 5 }, "labels": [ "enhancement", "up-for-grabs" ], "author": "danielhochman", "state": "open", "assignees": [ "yiminc" ], "change": "updated" } }, { "id": "event:7616fb6a49abd26d0091", "signalId": "github:temporalio/temporal:pull_request:11400", "event": "changed", "observedAt": "2026-08-13T13:48:00.446149Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11400", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "VLN-1587: remediate claude-code-action-unhardened", "text": "> 🏕️ This pull request was created by [camper](https://github.com/temporalio/camper), an automated security campaign tool. ## Finding
Ruleclaude-code-action-unhardened
SeverityMEDIUM
Repositorytemporalio/temporal
TicketVLN-1587
## Summary - `.github/workflows/claude-review-teams.yml`: Pinned `anthropics/claude-code-action` to the vetted v1.0.183 commit, disabled full output logging, disabled checkout credential persistence, and added Claude web-tool and turn limits while preserving the review bot's scoped PR review tooling. ## Instructions - **Approve** to merge this fix - **Request changes** to trigger a new remediation attempt - `/camper rebase` — rebase onto the base branch - `/camper close` — close this PR without merging - `/camper retry` — regenerate the fix from scratch against the current base", "url": "https://github.com/temporalio/temporal/pull/11400", "createdAt": "2026-08-03T14:19:40Z", "updatedAt": "2026-08-12T14:02:38Z", "timestamp": "2026-08-12T14:02:38Z", "metrics": { "reactions": 1, "comments": 2 }, "labels": [], "author": "picatz", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:9987c9b4a83a6ed241ab", "signalId": "github:temporalio/temporal:issue:11547", "event": "discovered", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:issue:11547", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "issue", "title": "A brief `Unavailable` blip resets History queue backoff, causing a sustained retry storm", "text": "### Summary When a History cluster is running at its system persistence-QPS limit, the fleet stays stable only because `ResourceExhausted` errors put queue readers/task executables onto their long reschedule backoff, which spreads persistence load out over time. If persistence briefly returns a *different* transient error (`Unavailable`, or context deadline exceeded) - e.g. during a database failover/switchover - readers/executables fall back to their fast retry path, the fleet's long-backoff state is effectively reset, and on recovery every shard re-fires in a synchronized burst. The aggregate read QPS then exceeds the system persistence limiter, ack-level advancement is starved, and the queues settle into a saturated equilibrium instead of draining. ### Environment - Temporal Server version: **v1.30.2** (behavior also present, byte-identical in the relevant code, on v1.31.1 and `main` - see code pointers) - Persistence: Aurora PostgreSQL - History service running at/near its configured **system** persistence-QPS limit ### Current behavior 1. Under chronic system-QPS pressure, a fraction of persistence ops trip `ResourceExhausted`. Readers/executables detect this specific class via `IsResourceExhausted(err)` and reschedule on the long `ResourceExhausted` backoff curve (`CreateTaskResourceExhaustedReschedulePolicy`: initial ~3s, coefficient 1.5, max ~5m), which naturally de-synchronizes the fleet. `RangeCompleteHistoryTasks` slips through often enough to keep ack levels advancing. No customer impact, but zero headroom. 2. A brief persistence interruption (observed ~60s during a DB switchover) returns `Unavailable` / context-deadline for calls - the incident logs show this window as `Unavailable`/deadline, not `ResourceExhausted`. 3. The long backoff is engaged **only** when the error is `ResourceExhausted`: - Readers: on `ResourceExhausted` they wait a fixed throttle delay; for any other transient error they use the fast exponential retrier (~50ms initial → ~1s max), which is then reset once a call succeeds. - Executables: they increment a per-task `resourceExhaustedCount` and take the long reschedule **only** while that error is `ResourceExhausted`; any other error path resets `resourceExhaustedCount = 0` and falls back to the default reschedule policy (~1s initial, 1.1 coefficient, ~3m max). For the duration of the blip, every reader/executable on every shard retries on its fast/default path and the accumulated long-backoff state is discarded fleet-wide. 4. On recovery, each shard's first successful read returns a full batch with `MoreTasks=true`, which triggers an immediate re-notification (no throttle between that batch and the next read). Thousands of shards across multiple scheduled queue categories become eligible at once. Each individual reader is still gated by its own rate limiter, so this is not a single reader spinning with zero gap - it is an **aggregate, fleet-wide** synchronized burst whose combined read QPS exceeds the system persistence cap. 5. `RangeCompleteHistoryTasks` (advances ack levels by deleting completed task ranges) goes through the **same** persistence rate limiter as the reads: `GetHistoryTasks`, `CompleteHistoryTask`, and `RangeCompleteHistoryTasks` all funnel through the same `allow()` gate (system + namespace + shard limiters). Under saturation it is throttled/failed alongside the reads, so ack levels don't advance, readers re-read the same ranges every cycle, and the limiter stays saturated. Archival tasks (which read history from persistence before writing the blob) fail the same way and reschedule, compounding read load. 6. Result: a stable \"saturated\" equilibrium. Individual task executions can succeed, but queues do not logically drain. Recovery only happens by scaling persistence and/or raising the QPS limit; the backlog then drains slowly. ### Expected behavior A short-lived `Unavailable`/deadline condition on a cluster that is otherwise persistence-rate-limited should not collapse the fleet's backoff and cause a persistent retry storm. Specifically: - Transient non-`ResourceExhausted` persistence errors should not discard readers'/executables' long-backoff state in a way that synchronizes the whole fleet on recovery. - Ack-level advancement (`RangeCompleteHistoryTasks`) should not have to compete on equal footing with the same reader load it is trying to relieve - otherwise there is no escape path from saturation. ### Impact Extended (multi-hour) stall of workflow progress across all shards on the affected cluster: workflow starts, signals, workflow-task completions, timer fires, and archival all intermittently fail or make no progress, even though the database itself is healthy after the blip. Frontend availability metrics understate the impact because affected shards make zero forward progress regardless of client retries. ### Suggested directions (for discussion) 1. Apply the congestion-style long/jittered backoff to a broader set of transient persistence errors - at minimum `Unavailable` and context-deadline - not just `ResourceExhausted`, so a brief outage doesn't reset the fleet to the fast curve. 2. Add jitter / de-synchronization to reader re-fire after recovery so shards don't dispatch in lockstep when persistence returns. 3. Give ack-level advancement (`RangeCompleteHistoryTasks`) priority or a separate budget from read traffic through the persistence limiter, so the queue always has an escape path from saturation. 4. Gate immediate `MoreTasks=true` re-fires (e.g. small jittered delay) so a synchronized fleet of recovery batches can't collectively produce a read burst that exceeds the persistence cap. ### Relevant code pointers - `common/util.go`: `CreateTaskResourceExhaustedReschedulePolicy` (the long backoff, applied specifically for resource-exhausted); `IsResourceExhausted` (the actual decision point that selects the long curve); `IsPersistenceTransientError` (treats both `Unavailable` and `ResourceExhausted` as transient/retryable, but only the latter gets the long reschedule). - `service/history/queues/reader.go`: fixed throttle delay on `ResourceExhausted` vs. the fast exponential retrier for other errors; `MoreTasks()` immediate re-notification. - `service/history/queues/executable.go`: `resourceExhaustedCount` (incremented only on `ResourceExhausted`, reset to `0` on any other outcome) selecting the long reschedule. - `common/persistence/persistence_rate_limited_clients.go`: `GetHistoryTasks`, `CompleteHistoryTask`, and `RangeCompleteHistoryTasks` all pass through the same `allow()` gate (shared system/namespace/shard rate limiters) - so ack-advancement competes with reads for the same budget. *(Code paths above verified identical at tags `v1.30.2`, `v1.31.1`, and `main`.)*", "url": "https://github.com/temporalio/temporal/issues/11547", "createdAt": "2026-08-13T16:15:43Z", "updatedAt": "2026-08-13T16:19:14Z", "timestamp": "2026-08-13T16:19:14Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "ggbata", "state": "open", "assignees": [], "change": "new" } }, { "id": "event:0e38c9bc6a9b481597b9", "signalId": "github:temporalio/temporal:pull_request:11546", "event": "discovered", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11546", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "fix(batcher): scope deterministic request IDs to the batch job ID", "text": "## What changed? Use the `jobID` parameter in the `deterministicRequestID` function to allow multiple batch operations to signal the same workflow. ## Why? Two batch operations that send the same signal to the same workflow/run ID will only send one signal, the second will be de-duped in the signal logic because the request ID was hashed from workflow id / run id / signal name. Including the batch job ID gives proper hashing to prevent these separate signals from being de-duped ## How did you test it? - [x] added new unit test(s) - [x] added new functional test(s) ## Potential risks NA, this is a bug fix.", "url": "https://github.com/temporalio/temporal/pull/11546", "createdAt": "2026-08-13T16:13:40Z", "updatedAt": "2026-08-13T16:18:00Z", "timestamp": "2026-08-13T16:18:00Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "spkane31", "state": "open", "assignees": [], "change": "new" } }, { "id": "event:9402210b0344e5b7f4f1", "signalId": "github:temporalio/temporal:pull_request:11542", "event": "discovered", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11542", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Release removed shared cluster test references", "text": "## What changed? Clear removed tests from the shared cluster's backing slice. ## Why? `sharedClusterT` shortened `activeTests` without clearing the removed interface slot. The backing array could therefore retain completed tests and their functional test state.", "url": "https://github.com/temporalio/temporal/pull/11542", "createdAt": "2026-08-13T15:47:53Z", "updatedAt": "2026-08-13T16:12:39Z", "timestamp": "2026-08-13T16:12:39Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "new" } }, { "id": "event:76aa31aafb143e8bddae", "signalId": "github:temporalio/temporal:pull_request:11541", "event": "discovered", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11541", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Attribute queue reader stuck attempts to a slice", "text": "## What changed? - count reader stuck attempts per slice and per owning reader instead of per wall clock second (`SetReaderWatermark` -> `SetSliceReadWatermark`) - report each stuck window once, and only when the alert was actually queued - track read progress for every reader rather than only the default one, and stop creating readers at `MaxReaderCount` - only split slices that genuinely overlap the stuck range, via a new `Range.CanSplitStrictly` ## Why? The attempt counter was keyed on the truncated fire time of the last loaded task. A shard that keeps generating tasks gets a new slice per notification and several of them can land in the same second, so every read made progress in its own slice while the shared counter still climbed — the policy fired on healthy shards. That is why `history.queueReaderStuckCriticalAttempts` is currently raised high enough to disable it in practice. Attributing attempts to a slice only counts repeated reads that fail to move past one fire time window *within a single slice*, which is the condition worth splitting out, and it needs no extra time threshold to tell the two apart. Progress is also keyed on the owning reader, so a slice moved whole to the next reader is judged on that reader's own reads instead of being demoted again on its first one. `Range.CanSplit` is inclusive at both bounds, so slices merely adjacent to the stuck window were split into empty pieces and merged into the next reader, creating that reader for nothing. ## How did you test it? - [x] built - [x] covered by existing tests - [x] added new unit test(s) `action_reader_stuck.go` had no test file before. The new table test covers every overlap shape, the reader count bound, and the merge into an existing next reader; each fix was confirmed to fail against the pre-fix logic. ## Potential risks Reader stuck is effectively disabled by config today, so this only changes production behaviour once `queueReaderStuckCriticalAttempts` is lowered again. Known limitation worth a decision before that happens: slice identity is not stable. `processNewRange` merges each new range into the reader's slices, and `MergeWithSlice` destroys and rebuilds them, so the attempt count restarts. That is safe in the sense that it can only delay detection, never cause a false positive, but on a shard that keeps generating timers the merge cadence can outrun `ReaderStuckCriticalAttempts` reads and hold detection off. Carrying progress across split/merge, or keying it on `(readerID, watermark, Range.InclusiveMin)` which survives a merge, would close that gap — both need their own eviction story, so they are left out of this change.", "url": "https://github.com/temporalio/temporal/pull/11541", "createdAt": "2026-08-13T15:41:46Z", "updatedAt": "2026-08-13T16:19:21Z", "timestamp": "2026-08-13T16:19:21Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "prathyushpv", "state": "open", "assignees": [], "change": "new" } }, { "id": "event:04655b2bdddd0e7d5249", "signalId": "github:temporalio/temporal:pull_request:11508", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt", "state" ], "signal": { "id": "github:temporalio/temporal:pull_request:11508", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Eliminate expected object leak suppressions", "text": "## What changed? - Unregister process-global gRPC resolver and OpenTelemetry logger state during lifecycle shutdown. - Close the test matching client RPC factory and clear removed test references. - Remove every `WithExpected` entry from `objectLeakOpts`. ## Why? The leak test was suppressing the cluster graph instead of enforcing that cluster-owned objects become collectible. These lifecycle fixes leave only the protobuf traversal prune. ## Testing - `go test -count=1 -tags test_dep ./common/membership -run 'TestGRPCResolver'` - `go test -count=1 ./temporal` - `go test -count=1 ./tests/testcore -run 'TestSharedClusterT_RemoveTestReleasesTest'` - `go test -count=1 ./tests/leakcheck -run '^$'` Replaces #11503.", "url": "https://github.com/temporalio/temporal/pull/11508", "createdAt": "2026-08-12T16:47:54Z", "updatedAt": "2026-08-13T15:55:24Z", "timestamp": "2026-08-13T15:55:24Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:a47159212bf0dea06b2b", "signalId": "github:temporalio/temporal:pull_request:11544", "event": "discovered", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11544", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Enforce zero expected object leaks", "text": "## What changed? Remove the final `FunctionalTestBase.testCluster.testBase*` expectation. `objectLeakOpts` now contains only the protobuf traversal prune and no expected leaks. ## Why? The preceding stack releases shared-test and process-global references. Together with the persistence ownership fixes in #11506 and #11507, functional test clusters become fully collectible. ## Testing - `go test -count=1 ./tests/leakcheck -run '^$'` - With #11506 and #11507 applied: `make LEAK_ITERS=5 LEAK_ITERS_WARMUP=2 LEAK_GC_SETTLE_TIMEOUT=10s LEAK_TIMEOUT=3m leak-test` Stacked on #11543. Also depends on #11506 and #11507.", "url": "https://github.com/temporalio/temporal/pull/11544", "createdAt": "2026-08-13T15:51:29Z", "updatedAt": "2026-08-13T15:51:29Z", "timestamp": "2026-08-13T15:51:29Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "new" } }, { "id": "event:1fd4384536d2cee2d175", "signalId": "github:temporalio/temporal:pull_request:11543", "event": "discovered", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11543", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Release process-global lifecycle registrations", "text": "## What changed? Tie test gRPC resolver registrations and OTEL logger registrations to Fx lifecycle hooks. Test matching clients also close their RPC factories during cleanup. The leak test drops the corresponding logger and host expectations. ## Why? The process-global resolver map and OTEL error handler retained cluster-owned state after shutdown. Lifecycle-owned registrations make startup and shutdown ownership explicit, including concurrent OTEL registrations. ## Testing - `go test -count=1 ./common/membership -run '^TestGRPCResolver'` - `go test -count=1 ./temporal -run '^TestOTELLoggerErrorHandler'` - `make LEAK_ITERS=5 LEAK_ITERS_WARMUP=2 LEAK_GC_SETTLE_TIMEOUT=10s LEAK_TIMEOUT=3m leak-test` Stacked on #11542.", "url": "https://github.com/temporalio/temporal/pull/11543", "createdAt": "2026-08-13T15:50:19Z", "updatedAt": "2026-08-13T15:50:19Z", "timestamp": "2026-08-13T15:50:19Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "new" } }, { "id": "event:780adbcd1ee38a6aae9c", "signalId": "github:temporalio/temporal:pull_request:11422", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11422", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Skip unbuildable replication tasks on stream sender instead of blocking", "text": "## What changed? Skip unbuildable replication tasks on stream sender instead of blocking the stream. The skip is logged and new metric ReplicationTaskSendSkipped added. ## Why? When the replication stream sender cannot build (\"convert\") a task, it retries and, once the retry budget is exhausted, returns an error that tears the stream down. On reconnect the sender resumes from the same watermark, hits the same unbuildable task, and blocks the whole shard's stream indefinitely. This change skips the task to unblock and logs, add a metric for the skipped task so that it could be investigated later. ## How did you test it? - [x] built - [x] run locally and tested manually - [ ] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s)", "url": "https://github.com/temporalio/temporal/pull/11422", "createdAt": "2026-08-05T15:53:14Z", "updatedAt": "2026-08-13T15:42:36Z", "timestamp": "2026-08-13T15:42:36Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation", "reliability-2026" ], "author": "qyc5937", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:c07b1a1d7aa592158eb1", "signalId": "github:temporalio/temporal:pull_request:11486", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11486", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Fix approximateSize undercounting on activity start and heartbeat paths", "text": "## What changed? Fixed bookkeeping of mutable state approximate size on the two paths that mutate an `ActivityInfo` without adding its bytes to the counter: `AddActivityTaskStartedEvent` (start), and the heartbeat handler, where `RetryLastWorkerIdentity` now moves into `UpdateActivityProgress`. ## Why? Both sites mutate the pointer `GetActivityInfo` returned, but don't alter the approximate size. ## How did you test it? - [X] built - [ ] run locally and tested manually - [ ] covered by existing tests - [X] added new unit test(s) - [ ] added new functional test(s) ## Potential risks The risk should be low. We will hit the mutable state size limit faster, but it would be proper accounting.", "url": "https://github.com/temporalio/temporal/pull/11486", "createdAt": "2026-08-11T22:57:47Z", "updatedAt": "2026-08-13T15:41:50Z", "timestamp": "2026-08-13T15:41:50Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "reliability-2026" ], "author": "simvlad", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:a12a546ec8ecfb4b1788", "signalId": "github:temporalio/temporal:pull_request:10200", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:10200", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Validator generator [WiP]", "text": "## What changed? Opt-in validator that exhaustively validate all protobuf fields in 1 place. ## Why? Adds semantic validation for protobufs as a thin layer before the proto request reaches actual business logic. ## How did you test it? - [ ] built - [ ] run locally and tested manually - [ ] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s)", "url": "https://github.com/temporalio/temporal/pull/10200", "createdAt": "2026-05-08T01:12:05Z", "updatedAt": "2026-08-13T15:39:41Z", "timestamp": "2026-08-13T15:39:41Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:b541fb85f70fb5a25185", "signalId": "github:temporalio/temporal:pull_request:11513", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11513", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Harden shared JUnit report IO", "text": "Strengthens the shared JUnit module's I/O contract. Reads reject trailing XML and include the source path in errors, while writes atomically replace the destination so interrupted writes cannot corrupt an existing report. It also exposes counter validation for canonical report renderers without imposing that invariant on legacy producers yet. Stack: depends on #11480. The testrunner boundary cleanup follows this one.", "url": "https://github.com/temporalio/temporal/pull/11513", "createdAt": "2026-08-12T22:05:45Z", "updatedAt": "2026-08-13T15:31:33Z", "timestamp": "2026-08-13T15:31:33Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:e932fa1bcc2faa6e3b42", "signalId": "github:temporalio/temporal:pull_request:11033", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11033", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Return test runner orchestration outcomes", "text": "Makes test execution return an exit code and error instead of terminating inside the orchestration loop. This lets final artifact failures, retry-validation failures, execution errors, timeouts, and normal pass/fail outcomes be tested directly while `Main` remains the only process-exit boundary. Stack: depends on #11518 and completes the canonical `go test -json` reporting pipeline.", "url": "https://github.com/temporalio/temporal/pull/11033", "createdAt": "2026-07-13T19:38:51Z", "updatedAt": "2026-08-13T15:30:46Z", "timestamp": "2026-08-13T15:30:46Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "test-all-dbs", "request-claude-review" ], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:0daf03c08467e882230e", "signalId": "github:temporalio/temporal:pull_request:11518", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11518", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Return report persistence errors", "text": "Makes crash and attempt-history persistence return errors to their callers. Intermediate writes remain best effort, final writes remain mandatory, and a focused test covers crash-report write failure without changing runner exit behavior yet. Stack: depends on #11517. Fallible runner orchestration follows this one.", "url": "https://github.com/temporalio/temporal/pull/11518", "createdAt": "2026-08-12T22:21:21Z", "updatedAt": "2026-08-13T15:30:41Z", "timestamp": "2026-08-13T15:30:41Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:dafc375e07eff7c4b5fc", "signalId": "github:temporalio/temporal:pull_request:11517", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11517", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Simplify test runner attempt state", "text": "Removes the temporary runner-level `attempt` wrapper now that execution facts live in `attemptResult`. The runner stores result history directly and computes per-attempt coverage paths without changing retry, persistence, or exit behavior. Stack: depends on #11516. Fallible runner orchestration follows this one.", "url": "https://github.com/temporalio/temporal/pull/11517", "createdAt": "2026-08-12T22:18:31Z", "updatedAt": "2026-08-13T15:30:38Z", "timestamp": "2026-08-13T15:30:38Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:20f60a3ce2cb64522139", "signalId": "github:temporalio/temporal:pull_request:11516", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11516", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Remove legacy JUnit report merger", "text": "Deletes the now-unused legacy JUnit wrapper, synthetic-report builder, retry merger, and tree helper. Tests consume shared `Testsuites` documents directly, and summary fixtures explicitly model the already-canonical failure details they exercise. Stack: depends on #11515. Runner orchestration follows this one.", "url": "https://github.com/temporalio/temporal/pull/11516", "createdAt": "2026-08-12T22:14:53Z", "updatedAt": "2026-08-13T15:30:33Z", "timestamp": "2026-08-13T15:30:33Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:d69a00a7ea9642eae8b5", "signalId": "github:temporalio/temporal:pull_request:11515", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11515", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Persist canonical test attempt history", "text": "Persists completed attempt history directly through the canonical JUnit renderer for both intermediate and final reports. The testrunner write boundary now rejects inconsistent counters, while the legacy merger remains present but unused so its deletion can be reviewed separately. Stack: depends on #11488. Legacy JUnit cleanup follows this one.", "url": "https://github.com/temporalio/temporal/pull/11515", "createdAt": "2026-08-12T22:12:35Z", "updatedAt": "2026-08-13T15:30:29Z", "timestamp": "2026-08-13T15:30:29Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:3ff82ea90e95806e237e", "signalId": "github:temporalio/temporal:pull_request:11488", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11488", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Drive test retries from attempt results", "text": "Moves retry selection, argument rewriting, and missing-rerun validation from JUnit into a focused retry policy over canonical attempt results. The existing report merge remains presentation-only, isolating this PR to execution policy. Stack: depends on #11514. Canonical history persistence follows this one.", "url": "https://github.com/temporalio/temporal/pull/11488", "createdAt": "2026-08-11T23:31:31Z", "updatedAt": "2026-08-13T15:30:25Z", "timestamp": "2026-08-13T15:30:25Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:8df072ce4d76d4834d3b", "signalId": "github:temporalio/temporal:pull_request:11514", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11514", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Render crash reports canonically", "text": "Routes the `report-crash` command through the canonical JUnit renderer introduced with attempt results. The command test now compares the parsed document semantically, and the obsolete legacy XML fixture is removed. Stack: depends on #11487. The retry-policy PR follows this one.", "url": "https://github.com/temporalio/temporal/pull/11514", "createdAt": "2026-08-12T22:10:10Z", "updatedAt": "2026-08-13T15:30:20Z", "timestamp": "2026-08-13T15:30:20Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:afaa942cd08555e5815e", "signalId": "github:temporalio/temporal:pull_request:11487", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11487", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Record canonical Go test attempt results", "text": "Runs `go test` directly with JSON output and records package-aware attempt results as the canonical execution facts. The recorder owns event attribution, diagnostics, timeouts, console output, and exact JUnit counters while the existing retry and merge path remains in place as a compatibility seam. Stack: depends on #11512. Canonical crash rendering and retry policy follow this one.", "url": "https://github.com/temporalio/temporal/pull/11487", "createdAt": "2026-08-11T23:31:23Z", "updatedAt": "2026-08-13T15:30:15Z", "timestamp": "2026-08-13T15:30:15Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:48bdffa997d0e88d04fa", "signalId": "github:temporalio/temporal:pull_request:11512", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11512", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Use generic JUnit documents at runner boundaries", "text": "Moves the testrunner's report input and output boundaries onto `tools/common/junit.Testsuites`. The existing retry merger remains unchanged behind that seam, so this is a behavior-preserving preparation for canonical attempt rendering. Stack: depends on #11513. The canonical attempt-results PR follows this one.", "url": "https://github.com/temporalio/temporal/pull/11512", "createdAt": "2026-08-12T22:00:08Z", "updatedAt": "2026-08-13T15:30:10Z", "timestamp": "2026-08-13T15:30:10Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:0724b5e3e573d44b8c9d", "signalId": "github:temporalio/temporal:pull_request:11505", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11505", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Track process-lifetime object leak baselines", "text": "## What changed? Add process-lifetime baselines to `objectleak`, ignore tiny pointer-free allocations that the runtime cannot track individually, and allow asynchronous cleanup the full settle timeout. ## Why? Make object leak reports actionable by distinguishing process-lifetime objects from leaks and avoiding runtime-induced false positives. Replaces #11313.", "url": "https://github.com/temporalio/temporal/pull/11505", "createdAt": "2026-08-12T16:47:47Z", "updatedAt": "2026-08-13T15:25:51Z", "timestamp": "2026-08-13T15:25:51Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:259141c25ee8db188049", "signalId": "github:temporalio/temporal:pull_request:11169", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11169", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "[CHASM] Support WithRequestID on UpdateComponent", "text": "## What changed? - `WithRequestID` now applies to `UpdateComponent`, enabling execution-level idempotency guarding via request ID. - When a request ID is passed as part of an `UpdateComponent` call (via API handler), it is persisted upon successful updateFn call. If it is already present, instead, `UpdateComponent` fails with a `FailedPrecondition`. - When a request ID is not passed in, a generated ID is still created for error tracing purposes, but it is not written to mutable state. - On transaction close, mutable state will sweep the oldest RequestIDs (with an `attach_time`) upon hitting the configured limit. - This will sweep both entries below a configurable max age, as well as past a certain hard length limit. ## Why? - Scheduler's `UpdateSchedule` and `PatchSchedule` are implemented as handlers that persist a signal in V1. V1 signals provide idempotency via their request IDs. Scheduler V2 doesn't make use of signals, so instead, it must record request IDs explicitly. - We reuse the existing map within mutable state. - We *must* fail with an explicit error (`FailedPrecondition`) instead of simply returning a zero value (as Signals would on repeated successful requests). This is because `UpdateComponent` can apply to API models that include response values (which we don't record, therefore, we can't return on subsequent calls). ## How did you test it? - [ ] built - [ ] run locally and tested manually - [ ] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s)", "url": "https://github.com/temporalio/temporal/pull/11169", "createdAt": "2026-07-21T00:51:10Z", "updatedAt": "2026-08-13T15:23:52Z", "timestamp": "2026-08-13T15:23:52Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "lina-temporal", "state": "open", "assignees": [ "fretz12" ], "change": "updated" } }, { "id": "event:3d65f91432dee2006ba1", "signalId": "github:temporalio/temporal:pull_request:11303", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "text", "updatedAt", "labels" ], "signal": { "id": "github:temporalio/temporal:pull_request:11303", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add replication stream lane wire protocol and receiver-side lane routing", "text": "> **Part 3 of a 5-PR series** building to replication stream namespace isolation (a restructuring of #10147): read buffer → reader group → lane protocol → isolation manager → sender isolation. > #11302 (reader group) has merged, so this PR's diff is now standalone against `main`. · **Next in series: #11304** (isolation manager). ## What changed? The wire-level building blocks for per-namespace lane isolation, receiver side only: - **Proto**: `SyncReplicationState` gains `pause_high_namespace_ids` (namespaces the receiver reports as overwhelming the HIGH lane — the priority lives in the field name, so a future LOW extension adds its own field rather than widening this one), `isolated_lane_states` (per-lane applied watermarks keyed by namespace ID — with the documented caveat that a missing key is ambiguous between \"not tracked yet\" and \"retired and drained\", so a sender must never treat absence alone as drain proof), and `supports_namespace_isolation` (capability advertisement, so a sender never emits lane-tagged traffic to a receiver that would misroute it). `WorkflowReplicationMessages` gains `isolated_namespace_id` — when set, the batch belongs to that namespace's dedicated lane — and `retire_isolated_lane`, marking a lane's final message. - **Receiver**: lane-tagged batches route to lazily-created per-namespace task trackers. Each lane is its own monotonic stream for the life of the connection — there is no rewind or rotation machinery, because the sender-side design (later in the series) gives every lane a single owner cursor that never goes backwards. Member-lane watermarks fold into the overall ack minimum (cleanup safety) and are reported per lane; member-lane backlogs count toward HIGH flow control. Lane lifecycle is defensive about ordering: a batch's tasks are tracked BEFORE its retire flag is applied (so the concurrent ack loop can never delete a lane whose final batch is mid-track), a retiring lane is only dropped once it is drained AND has tracked at least one batch, and non-retire traffic arriving on a retiring lane revives it (the sender re-isolated the namespace before the lane drained). Lane-tagged traffic at any priority other than HIGH is a protocol violation and fails the stream rather than silently mis-acking (isolation splits the HIGH lane only). Lanes created concurrently with `Stop()` are pre-cancelled so no tasks run after shutdown. - **`NamespaceThrottler`** interface (default: noop, via fx) observes per-namespace HIGH-priority task load and decides which namespaces to report. The sender does not tag lanes yet, so this is inert until the sender-side isolation lands. ## Why? Isolation needs a wire contract before the sender can use it: capability advertisement, per-lane routing and progress reporting, and the throttled-namespace feedback channel. Landing the receiver first makes mixed-version clusters safe by construction. Compared to #10147, lanes are per-namespace rather than shared per severity tier — which is what eliminates that design's cursor rewinds and the watermark-regression/tracker-rotation protocol this PR previously needed to compensate for them. ## How did you test it? - [x] built - [x] covered by existing tests - [x] added new unit test(s) — lane routing (priority routing when unset, per-namespace tracker identity, non-HIGH rejection), retirement lifecycle (drop once drained, never-tracked retiring lane survives the ack snapshot, revive on re-isolation traffic, fresh lane after drop), and post-Stop lane creation being pre-cancelled - [x] added new functional test(s) — exercised end-to-end by the xdc test in the final PR of the series ## Potential risks Inert until a sender emits `isolated_namespace_id`, which is gated behind both a config flag and the capability advertisement. Receiver-side lane state is bounded by the sender's isolation cap (final PR). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- > [!NOTE] > **Medium Risk** > Touches replication ack watermarks and task routing on a critical path, but lane traffic is unused until the sender lands and the default throttler is a noop. > > **Overview** > Adds the **wire contract and receiver behavior** for per-namespace HIGH-lane isolation on workflow replication streams, ahead of sender-side isolation in a follow-up PR. > > **Proto:** `SyncReplicationState` now carries `pause_high_namespace_ids` (shard-scoped throttle feedback), `isolated_lane_states` (per-namespace applied watermarks), and `supports_namespace_isolation` (tiered-stack capability). `WorkflowReplicationMessages` adds `isolated_namespace_id` and `retire_isolated_lane` for lane-tagged batches. > > **Receiver:** Lane-tagged HIGH traffic routes to lazily created per-namespace trackers; member-lane backlog counts toward HIGH flow control and member watermarks fold into the overall ack minimum. Acks report throttled namespaces via a new **`NamespaceThrottler`** hook (default **noop** in fx). Lifecycle handling covers track-before-retire ordering, drained retired lanes, re-isolation reviving retiring lanes, non-HIGH lane tags failing the stream, and post-`Stop()` lanes pre-cancelled. > > Behavior stays **inert** until a future sender emits `isolated_namespace_id` (gated on capability advertisement). > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 1140765a76ca8afc5b2c3f80dc6014abd8076182. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot). ", "url": "https://github.com/temporalio/temporal/pull/11303", "createdAt": "2026-07-27T12:22:32Z", "updatedAt": "2026-08-13T15:23:21Z", "timestamp": "2026-08-13T15:23:21Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation", "reliability-2026" ], "author": "robholland", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:9e9740da10e3cda69e51", "signalId": "github:temporalio/temporal:pull_request:11533", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt", "state" ], "signal": { "id": "github:temporalio/temporal:pull_request:11533", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Update test shard salt", "text": "Automatically generated by the optimize-test-sharding workflow.", "url": "https://github.com/temporalio/temporal/pull/11533", "createdAt": "2026-08-13T07:33:14Z", "updatedAt": "2026-08-13T15:03:18Z", "timestamp": "2026-08-13T15:03:18Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "temporal-cicd[bot]", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:abac01697ee5c57805a3", "signalId": "github:temporalio/temporal:pull_request:10643", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt", "state" ], "signal": { "id": "github:temporalio/temporal:pull_request:10643", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Downscale test runner size, increase shards", "text": "## What changed? Only use 4-core ARM runners instead of 8-core; and increase shard size for test sharding. ## Why? 8-core runners have - at least during peak hours - very long provisioning time (several minutes). By using 4-core we reduce that time, but risk OOM kills as they have less memory. To counter that, we increase the number of test shards so that fewer tests are run per shard.", "url": "https://github.com/temporalio/temporal/pull/10643", "createdAt": "2026-06-10T17:58:11Z", "updatedAt": "2026-08-13T14:57:11Z", "timestamp": "2026-08-13T14:57:11Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "test-all-dbs" ], "author": "stephanos", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:ab22fe1a0c9ae1769b99", "signalId": "github:temporalio/temporal:pull_request:11465", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11465", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add isolated functional test clusters", "text": "## Summary - give every testcore.NewEnv test a fresh cluster and tear it down with the test - bound concurrently live clusters to GOMAXPROCS by default, configurable with TEMPORAL_TEST_LIVE_CLUSTERS - preseed the primary and external namespaces for each cluster before server startup - preserve bounded legacy suite-owned cluster paths and suite-level worker-service requirements - retain lightweight optional JSONL lifecycle, boot-phase, runtime, and RSS reporting - build on #10643 for the lower-resource CI shard layout and its persistence prerequisites The shared pool, dedicated-cluster marker, warm spares, duplicate SQL/SQLite lease work, Cassandra reuse pool, and heavyweight report generator are intentionally removed from this PR. FASTBOOT.md retains the investigation history and current conclusions. ## Testing - make fmt lint - go test -race -tags=test_dep ./tests/testcore - go test -race -tags=test_dep ./tests -run ^TestClientDataConverterTestSuite$ -count=1 - go test -race -tags=test_dep ./tests -run ^TestWorkflowAliasSearchAttributeTestSuite$ -count=1", "url": "https://github.com/temporalio/temporal/pull/11465", "createdAt": "2026-08-11T02:58:59Z", "updatedAt": "2026-08-13T14:57:10Z", "timestamp": "2026-08-13T14:57:10Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "test-all-dbs" ], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:9ab8f4bd99248a9840f3", "signalId": "github:temporalio/temporal:pull_request:11480", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt", "state" ], "signal": { "id": "github:temporalio/temporal:pull_request:11480", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Extract shared JUnit XML handling", "text": "## What changed? Extract generic JUnit XML file reading and writing into `tools/common/junit`. ## Why? Centralizing format-level JUnit handling.", "url": "https://github.com/temporalio/temporal/pull/11480", "createdAt": "2026-08-11T20:57:07Z", "updatedAt": "2026-08-13T14:54:22Z", "timestamp": "2026-08-13T14:54:22Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [ "request-claude-review" ], "author": "stephanos", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:84f16993fb191a0f5297", "signalId": "github:temporalio/temporal:pull_request:11461", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt", "state" ], "signal": { "id": "github:temporalio/temporal:pull_request:11461", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Standardize Claude review comments", "text": "Standardize Claude review comment format, style and focus.", "url": "https://github.com/temporalio/temporal/pull/11461", "createdAt": "2026-08-10T22:54:30Z", "updatedAt": "2026-08-13T14:54:05Z", "timestamp": "2026-08-13T14:54:05Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "stephanos", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:1fd8a952342d4257f187", "signalId": "github:temporalio/temporal:pull_request:11526", "event": "changed", "observedAt": "2026-08-13T16:19:22.035158Z", "changedFields": [ "updatedAt", "state" ], "signal": { "id": "github:temporalio/temporal:pull_request:11526", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Fix flakereport incomplete JUnit failures", "url": "https://github.com/temporalio/temporal/pull/11526", "createdAt": "2026-08-13T01:11:18Z", "updatedAt": "2026-08-13T14:53:28Z", "timestamp": "2026-08-13T14:53:28Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:c0e419aa5e889894b61b", "signalId": "github:temporalio/temporal:pull_request:11543", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "text", "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11543", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Release process-global lifecycle registrations", "text": "## What changed? Tie gRPC resolver registrations and OTEL logger registrations to their owners. Test resolver callers now receive and register cleanup directly, and matching test clients close their RPC factories during cluster shutdown. The leak test drops the corresponding logger, host, and final testBase expectations, so it no longer allows expected object leaks. ## Why? The process-global resolver map and OTEL error handler retained cluster-owned state after shutdown. Explicit cleanup releases those references while preserving resolver availability during Fx graph construction. ## Testing - go test -race -tags disable_grpc_modules,test_dep ./common/membership ./common/rpc/test ./temporal ./tests/testcore -count=1 - make LEAK_ITERS=5 LEAK_ITERS_WARMUP=2 LEAK_GC_SETTLE_TIMEOUT=30s LEAK_TIMEOUT=4m leak-test The package tests pass. The zero-expected-leak gate depends on the persistence ownership fixes in #11506 and #11507; without them, the leak test reports the remaining testBase persistence graph. Stacked on #11542.", "url": "https://github.com/temporalio/temporal/pull/11543", "createdAt": "2026-08-13T15:50:19Z", "updatedAt": "2026-08-13T17:42:59Z", "timestamp": "2026-08-13T17:42:59Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:c5d22ab6554b21774fcd", "signalId": "github:temporalio/temporal:pull_request:11546", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "updatedAt", "metrics", "labels", "state" ], "signal": { "id": "github:temporalio/temporal:pull_request:11546", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "fix(batcher): scope deterministic request IDs to the batch job ID", "text": "## What changed? Use the `jobID` parameter in the `deterministicRequestID` function to allow multiple batch operations to signal the same workflow. ## Why? Two batch operations that send the same signal to the same workflow/run ID will only send one signal, the second will be de-duped in the signal logic because the request ID was hashed from workflow id / run id / signal name. Including the batch job ID gives proper hashing to prevent these separate signals from being de-duped ## How did you test it? - [x] added new unit test(s) - [x] added new functional test(s) ## Potential risks NA, this is a bug fix.", "url": "https://github.com/temporalio/temporal/pull/11546", "createdAt": "2026-08-13T16:13:40Z", "updatedAt": "2026-08-13T17:38:09Z", "timestamp": "2026-08-13T17:38:09Z", "metrics": { "reactions": 0, "comments": 2 }, "labels": [ "reliability-2026" ], "author": "spkane31", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:7a2dc2d10b261a644c0d", "signalId": "github:temporalio/temporal:pull_request:11033", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "text", "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11033", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Return test runner orchestration outcomes", "text": "Makes test execution return an exit code and error instead of terminating inside the orchestration loop. Final artifact failures, retry-validation failures, execution errors, timeouts, and normal pass/fail outcomes are tested directly while Main remains the process-exit seam. Stack: depends on #11518 and completes the canonical Go test JSON reporting pipeline.", "url": "https://github.com/temporalio/temporal/pull/11033", "createdAt": "2026-07-13T19:38:51Z", "updatedAt": "2026-08-13T17:32:26Z", "timestamp": "2026-08-13T17:32:26Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "test-all-dbs", "request-claude-review" ], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:1b51bd0b601e3973d99c", "signalId": "github:temporalio/temporal:pull_request:11518", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "title", "text", "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11518", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Adopt canonical test reporting pipeline", "text": "Switches orchestration to canonical attempt results and JUnit rendering, then removes the legacy JUnit merger and temporary diagnostic adapter in the same PR. Intermediate and final artifacts come from one attempt history, and report writes reject inconsistent counters. Stack: depends on #11517. Explicit orchestration outcomes follow in #11033.", "url": "https://github.com/temporalio/temporal/pull/11518", "createdAt": "2026-08-12T22:21:21Z", "updatedAt": "2026-08-13T17:32:23Z", "timestamp": "2026-08-13T17:32:23Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:ef6a8a0419ea9170b2b1", "signalId": "github:temporalio/temporal:pull_request:11517", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "title", "text", "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11517", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Render JUnit from canonical attempt results", "text": "Adds the pure canonical attempt-history renderer, including parent-failure suppression, diagnostics, timeouts, aborts, build errors, retry suffixes, crash reports, exact counters, and numeric durations. Integration coverage verifies the persisted JUnit shape and the downstream sharding consumer. Stack: depends on #11516. The production cutover follows in #11518.", "url": "https://github.com/temporalio/temporal/pull/11517", "createdAt": "2026-08-12T22:18:31Z", "updatedAt": "2026-08-13T17:32:21Z", "timestamp": "2026-08-13T17:32:21Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:78c8cf28477f47369442", "signalId": "github:temporalio/temporal:pull_request:11516", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "title", "text", "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11516", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Plan test retries from canonical results", "text": "Moves retry selection, argument rewriting, and missing-rerun validation into a focused policy over canonical attempt results. The current runner still owns orchestration, so this PR changes the decision module without switching the reporting pipeline. Stack: depends on #11515. Canonical JUnit rendering follows in #11517.", "url": "https://github.com/temporalio/temporal/pull/11516", "createdAt": "2026-08-12T22:14:53Z", "updatedAt": "2026-08-13T17:32:18Z", "timestamp": "2026-08-13T17:32:18Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:75ed4a81bae28bd632a6", "signalId": "github:temporalio/temporal:pull_request:11515", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "title", "text", "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11515", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Record canonical Go test attempt results", "text": "Runs Go tests directly with JSON output and records package-aware canonical attempt results. The recorder owns event attribution, build failures, diagnostics, timeouts, console output, process state, and coverage-path handling, with focused unit and subprocess tests. Stack: depends on #11488. Retry policy follows in #11516.", "url": "https://github.com/temporalio/temporal/pull/11515", "createdAt": "2026-08-12T22:12:35Z", "updatedAt": "2026-08-13T17:32:16Z", "timestamp": "2026-08-13T17:32:16Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:97149a7826f49beb57f3", "signalId": "github:temporalio/temporal:pull_request:11488", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "title", "text", "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11488", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Scope test diagnostics to canonical results", "text": "Converts test output analysis to package-aware canonical diagnostics and failure evidence. The existing runner reaches the new implementation through a temporary compatibility adapter, so there is still one parser implementation while the production cutover remains isolated. Stack: depends on #11514. The Go test JSON recorder follows in #11515.", "url": "https://github.com/temporalio/temporal/pull/11488", "createdAt": "2026-08-11T23:31:31Z", "updatedAt": "2026-08-13T17:28:40Z", "timestamp": "2026-08-13T17:28:40Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:dc86d06509eacf7ad4b1", "signalId": "github:temporalio/temporal:pull_request:11487", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "title", "text", "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11487", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Separate test diagnostics and timeout parsing", "text": "Separates diagnostic parsing and timeout parsing into focused files without changing behavior. Existing comments and tests move with their implementations so the later canonical conversion is a semantic diff instead of a delete-and-add rewrite. Stack: depends on #11512. The canonical result model follows in #11514.", "url": "https://github.com/temporalio/temporal/pull/11487", "createdAt": "2026-08-11T23:31:23Z", "updatedAt": "2026-08-13T17:28:37Z", "timestamp": "2026-08-13T17:28:37Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:2bbc46a6d0e836b33713", "signalId": "github:temporalio/temporal:pull_request:11512", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "text", "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11512", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Use generic JUnit documents at runner boundaries", "text": "Moves testrunner report inputs, outputs, and summaries onto the shared JUnit document types. The existing reporting behavior remains unchanged behind that seam. Stack: depends on #11513. Parser separation follows in #11487.", "url": "https://github.com/temporalio/temporal/pull/11512", "createdAt": "2026-08-12T22:00:08Z", "updatedAt": "2026-08-13T17:28:36Z", "timestamp": "2026-08-13T17:28:36Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:a22a32e30e4bee2b1ed7", "signalId": "github:temporalio/temporal:pull_request:11513", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "text", "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11513", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Harden shared JUnit report IO", "text": "Strengthens shared JUnit reads and writes. Reads reject trailing XML and include the source path in errors. Writes validate counters and atomically replace the destination so interrupted writes cannot corrupt an existing report. This is the bottom of the testrunner reporting stack.", "url": "https://github.com/temporalio/temporal/pull/11513", "createdAt": "2026-08-12T22:05:45Z", "updatedAt": "2026-08-13T17:28:34Z", "timestamp": "2026-08-13T17:28:34Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:9c5074190e0ec00d730d", "signalId": "github:temporalio/temporal:pull_request:11514", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "title", "text", "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11514", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Define canonical Go test attempt results", "text": "Defines the package-aware canonical attempt model and its queries for failed leaves, incomplete executions, package aborts, runtime failures, process failures, and retry safety. Tests construct results directly and pin these invariants before production uses the model. Stack: depends on #11487. Scoped canonical diagnostics follow in #11488.", "url": "https://github.com/temporalio/temporal/pull/11514", "createdAt": "2026-08-12T22:10:10Z", "updatedAt": "2026-08-13T17:28:38Z", "timestamp": "2026-08-13T17:28:38Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:bce75df4e291b5440cbc", "signalId": "github:temporalio/temporal:pull_request:11527", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11527", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Fix sticky queue stats zeroed out", "text": "## What Skip the versioning attribution logic when computing stats for sticky queues. Otherwise, we end up with 0 value for add and dispatch rates. This breaks poller autoscaling for sticky queues: 0/0 = NaN, and NaN > threshold is always false, so no +1 scaling signals are ever emitted. Background DescribeTaskQueue returns stats like add_rate and dispatch_rate. For versioned task queues, these stats are obtained from the unversioned physical queue. So when we query the stats for the unversioned queue, we subtract the stats already attributed to the versioned queue. This way, we don't double count. Sticky queues on the other hand are not versioned; they only have the unversioned physical queue. So the above logic is not applicable. Since sticky queue inherits the user data from the normal queue, it was incorrectly treated as versioned. ## How did you test it? Unit tests 🤖 Generated with [Claude Code](https://claude.com/claude-code)", "url": "https://github.com/temporalio/temporal/pull/11527", "createdAt": "2026-08-13T01:42:36Z", "updatedAt": "2026-08-13T17:26:40Z", "timestamp": "2026-08-13T17:26:40Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "rkannan82", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:a75adc000fdb49f791d1", "signalId": "github:temporalio/temporal:pull_request:11548", "event": "discovered", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11548", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "fix time-skipping flaky tests", "text": "## What changed? fix the flaky test of time skipping`CanceledTimerNotUsedAsSkipTarget`", "url": "https://github.com/temporalio/temporal/pull/11548", "createdAt": "2026-08-13T16:34:53Z", "updatedAt": "2026-08-13T17:11:56Z", "timestamp": "2026-08-13T17:11:56Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "feiyang3cat", "state": "open", "assignees": [], "change": "new" } }, { "id": "event:b79f34dc28cfe2182328", "signalId": "github:temporalio/temporal:pull_request:11481", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11481", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Skip worker commands task queues in missing TQ check", "text": "## What Skip worker commands task queues (`temporal-sys/worker-commands/...`) when checking for missing task queues during version promotion (SetCurrent / SetRamping). ## Why An SDK bug caused version attributes to be set on worker commands queues, registering them in a deployment version. These queues are ephemeral and don't support versioning, so `IsVersionMissingTaskQueues` would incorrectly flag them as missing and block version promotion. ## How did you test it? Unit tests for `checkForMissingTaskQueues`: - Worker commands TQ in prev version is excluded from missing list - User TQ missing from new version is still reported - All TQs present returns empty", "url": "https://github.com/temporalio/temporal/pull/11481", "createdAt": "2026-08-11T22:22:30Z", "updatedAt": "2026-08-13T17:05:59Z", "timestamp": "2026-08-13T17:05:59Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "rkannan82", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:6a6802bb6ee59f771245", "signalId": "github:temporalio/temporal:pull_request:11544", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "updatedAt", "metrics", "state" ], "signal": { "id": "github:temporalio/temporal:pull_request:11544", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Enforce zero expected object leaks", "text": "## What changed? Remove the final `FunctionalTestBase.testCluster.testBase*` expectation. `objectLeakOpts` now contains only the protobuf traversal prune and no expected leaks. ## Why? The preceding stack releases shared-test and process-global references. Together with the persistence ownership fixes in #11506 and #11507, functional test clusters become fully collectible. ## Testing - `go test -count=1 ./tests/leakcheck -run '^$'` - With #11506 and #11507 applied: `make LEAK_ITERS=5 LEAK_ITERS_WARMUP=2 LEAK_GC_SETTLE_TIMEOUT=10s LEAK_TIMEOUT=3m leak-test` Stacked on #11543. Also depends on #11506 and #11507.", "url": "https://github.com/temporalio/temporal/pull/11544", "createdAt": "2026-08-13T15:51:29Z", "updatedAt": "2026-08-13T17:01:38Z", "timestamp": "2026-08-13T17:01:38Z", "metrics": { "reactions": 0, "comments": 1 }, "labels": [], "author": "stephanos", "state": "closed", "assignees": [], "change": "updated" } }, { "id": "event:8fddd660b47e46340bee", "signalId": "github:temporalio/temporal:pull_request:11541", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "text", "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11541", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Attribute queue reader stuck attempts to a slice", "text": "## What changed? - count reader stuck attempts per slice and per owning reader instead of per wall clock second (`SetReaderWatermark` -> `SetSliceReadWatermark`) - report each stuck window once, and only when the alert was actually queued - track read progress for every reader rather than only the default one, and stop creating readers at `MaxReaderCount` - only split slices that genuinely overlap the stuck range, via a new `Range.CanSplitStrictly` ## Why? The attempt counter was keyed on the truncated fire time of the last loaded task. A shard that keeps generating tasks gets a new slice per notification and several of them can land in the same second, so every read made progress in its own slice while the shared counter still climbed — the policy fired on healthy shards. That is why `history.queueReaderStuckCriticalAttempts` is currently raised high enough to disable it in practice. Attributing attempts to a slice only counts repeated reads that fail to move past one fire time window *within a single slice*, which is the condition worth splitting out, and it needs no extra time threshold to tell the two apart. Progress is also keyed on the owning reader, so a slice moved whole to the next reader is judged on that reader's own reads instead of being demoted again on its first one. `Range.CanSplit` is inclusive at both bounds, so slices merely adjacent to the stuck window were split into empty pieces and merged into the next reader, creating that reader for nothing. ## How did you test it? - [x] built - [x] covered by existing tests - [x] added new unit test(s) `action_reader_stuck.go` had no test file before. The new table test covers every overlap shape, the reader count bound, and the merge into an existing next reader. Each fix was confirmed to fail against the pre-fix logic, including that the reader attributes progress to the slice and reader it actually read with. ## Potential risks Reader stuck is effectively disabled by config today, so this only changes production behaviour once `queueReaderStuckCriticalAttempts` is lowered again. Tracking non-default readers means the last reader can now alert for a window nothing can be done about, since there is no lower priority reader to move it to. The report-once latch bounds that to one alert per slice and window, but each one still costs a checkpoint. Known limitation worth a decision before the config is lowered: slice identity is not stable. `processNewRange` merges each new range into the reader's slices, and `MergeWithSlice` destroys and rebuilds them, so the attempt count restarts. That can only delay detection, never cause a false positive, but on a shard that keeps generating timers the merge cadence can outrun `ReaderStuckCriticalAttempts` reads and hold detection off. Carrying progress across split/merge, or keying it on `(readerID, watermark, Range.InclusiveMin)` which survives a merge, would close the gap — both need their own eviction story, so they are left out here.", "url": "https://github.com/temporalio/temporal/pull/11541", "createdAt": "2026-08-13T15:41:46Z", "updatedAt": "2026-08-13T16:43:30Z", "timestamp": "2026-08-13T16:43:30Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "prathyushpv", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:565c1aafc0c210519138", "signalId": "github:temporalio/temporal:pull_request:11303", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "text", "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11303", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add replication stream lane wire protocol and receiver-side lane routing", "text": "> **Part 3 of a 5-PR series** building to replication stream namespace isolation (a restructuring of #10147): read buffer → reader group → lane protocol → isolation manager → sender isolation. > #11302 (reader group) has merged, so this PR's diff is now standalone against `main`. · **Next in series: #11304** (isolation manager). ## What changed? The wire-level building blocks for per-namespace lane isolation, receiver side only: - **Proto**: `SyncReplicationState` gains `pause_high_namespace_ids` (namespaces the receiver reports as overwhelming the HIGH lane — the priority lives in the field name, so a future LOW extension adds its own field rather than widening this one), `isolated_lane_states` (per-lane applied watermarks keyed by namespace ID — with the documented caveat that a missing key is ambiguous between \"not tracked yet\" and \"retired and drained\", so a sender must never treat absence alone as drain proof), and `supports_namespace_isolation` (capability advertisement, so a sender never emits lane-tagged traffic to a receiver that would misroute it). `WorkflowReplicationMessages` gains `isolated_namespace_id` — when set, the batch belongs to that namespace's dedicated lane — and `retire_isolated_lane`, marking a lane's final message. - **Receiver**: lane-tagged batches route to lazily-created per-namespace task trackers. Each lane is its own monotonic stream for the life of the connection — there is no rewind or rotation machinery, because the sender-side design (later in the series) gives every lane a single owner cursor that never goes backwards. Member-lane watermarks fold into the overall ack minimum (cleanup safety) and are reported per lane; member-lane backlogs count toward HIGH flow control. Lane lifecycle is defensive about ordering: a batch's tasks are tracked BEFORE its retire flag is applied (so the concurrent ack loop can never delete a lane whose final batch is mid-track), a retiring lane is only dropped once it is drained AND has tracked at least one batch, and non-retire traffic arriving on a retiring lane revives it (the sender re-isolated the namespace before the lane drained). Lane-tagged traffic at any priority other than HIGH is a protocol violation and fails the stream rather than silently mis-acking (isolation splits the HIGH lane only). Lanes created concurrently with `Stop()` are pre-cancelled so no tasks run after shutdown. - **`NamespaceThrottler`** interface (default: noop, via fx) observes per-namespace HIGH-priority task load and decides which namespaces to report. The sender does not tag lanes yet, so this is inert until the sender-side isolation lands. ## Why? Isolation needs a wire contract before the sender can use it: capability advertisement, per-lane routing and progress reporting, and the throttled-namespace feedback channel. Landing the receiver first makes mixed-version clusters safe by construction. Compared to #10147, lanes are per-namespace rather than shared per severity tier — which is what eliminates that design's cursor rewinds and the watermark-regression/tracker-rotation protocol this PR previously needed to compensate for them. ## How did you test it? - [x] built - [x] covered by existing tests - [x] added new unit test(s) — lane routing (priority routing when unset, per-namespace tracker identity, non-HIGH rejection), retirement lifecycle (drop once drained, never-tracked retiring lane survives the ack snapshot, revive on re-isolation traffic, fresh lane after drop), and post-Stop lane creation being pre-cancelled - [x] added new functional test(s) — exercised end-to-end by the xdc test in the final PR of the series ## Potential risks Inert until a sender emits `isolated_namespace_id`, which is gated behind both a config flag and the capability advertisement. Receiver-side lane state is bounded by the sender's isolation cap (final PR). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- > [!NOTE] > **Medium Risk** > Touches replication ack watermarks and stream failure modes in tiered-stack mode, but lane traffic is unused until the sender ships and default throttler is noop. > > **Overview** > Adds the **wire contract and receiver-side behavior** for per-namespace replication stream isolation (sender lane tagging lands in a follow-up PR). > > **Proto** extends `SyncReplicationState` with `pause_high_namespace_ids`, per-namespace `isolated_lane_states`, and `supports_namespace_isolation`. `WorkflowReplicationMessages` gains `isolated_namespace_id` and `retire_isolated_lane` for lane-tagged batches and lane teardown. > > **Stream receiver** routes lane-tagged HIGH batches to lazily created per-namespace trackers, folds member-lane watermarks into the overall ack minimum, counts member-lane backlog in HIGH flow control, and reports throttled namespaces via a new **`NamespaceThrottler`** hook (default noop in fx). Tiered-stack acks advertise isolation support; non-HIGH lane-tagged traffic fails the stream. > > Behavior is **inert** until a sender sets `isolated_namespace_id`; existing streams unchanged. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit b839cba487a681767dbe799bd66d3694b995beb5. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot). ", "url": "https://github.com/temporalio/temporal/pull/11303", "createdAt": "2026-07-27T12:22:32Z", "updatedAt": "2026-08-13T16:35:29Z", "timestamp": "2026-08-13T16:35:29Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation", "reliability-2026" ], "author": "robholland", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:7814121d9279d77323f9", "signalId": "github:temporalio/temporal:pull_request:11535", "event": "changed", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [ "text", "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11535", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Update Selected API list.", "text": "## What changed? Added more state-effecting API calls to the forwarding list. ## Why? The intent is for passive to always forward those APIs it cannot handle locally. ## How did you test it? - [x] built - [ ] run locally and tested manually - [x] covered by existing tests - [ ] added new unit test(s) - [ ] added new functional test(s) --- > [!NOTE] > **Medium Risk** > Changes which cross-cluster RPCs are auto-forwarded for global namespaces; misconfiguration could leave state changes on passive clusters or alter failover behavior for new API types. > > **Overview** > Expands **selected-apis-forwarding** so passive clusters forward additional **state-effecting** RPCs to the namespace’s active cluster. > > **Workflow APIs** newly whitelisted: `UpdateWorkflowExecution`, `PauseWorkflowExecution`, `UnpauseWorkflowExecution`, `ResetWorkflowExecution`, and `ExecuteMultiOperation`. Policy comments now describe forwarding as state-effecting APIs and point readers at `selectedAPIsForwardingRedirectionPolicyWhitelistedAPIs` instead of an inline list. > > Tests add **`TestSelectedAPIs`** to assert the full whitelist (workflow, standalone activity, and Nexus operation APIs). The non-whitelisted API case is fixed by suffixing API names with `_notwhitelisted` and using a global namespace whose active cluster is remote, so forwarding tests no longer accidentally exercise whitelisted names. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 07fed6a663b2075bbf4a241043dbda346847d619. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot). ", "url": "https://github.com/temporalio/temporal/pull/11535", "createdAt": "2026-08-13T11:31:39Z", "updatedAt": "2026-08-13T16:22:10Z", "timestamp": "2026-08-13T16:22:10Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation" ], "author": "robholland", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:1280d99b78c7ade91744", "signalId": "github:temporalio/temporal:pull_request:11304", "event": "discovered", "observedAt": "2026-08-13T17:43:20.785491Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11304", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Add isolation manager for per-namespace replication lanes", "text": "> **Part 4 of a 5-PR series** building to replication stream namespace isolation (a restructuring of #10147): read buffer → reader group → lane protocol → isolation manager → sender isolation. > **Stacked on #11303** (lane wire protocol). This PR targets `main`, so until the earlier PRs in the series merge its diff also includes their commits — review after they land. · **Next in series: #11305** (sender isolation). ## What changed? `isolationManager`: the sender-side state machine for HIGH-lane namespace isolation. Each namespace the receiver reports as overwhelming the shared HIGH (live) lane is split onto its own dedicated lane — an independent read cursor and wire stream, paced by a throttled severity tier (a rate class). Because every member owns its cursor: - members never interact — joining, demoting, or graduating one namespace moves no other namespace's position; - **no cursor ever rewinds**, so there is no CAS machinery, no rewind-point arithmetic, and no receiver-side tracker rotation (all of which the shared-tier-cursor design in #10147 required); - demotion is purely a rate-class change that moves no data. Lane transitions still anchor on applied (acked) watermarks so ordered HIGH events never straddle a hand-off with a gap: a split floors the member at the shared lane's acked watermark, and graduation is gated on the member's lane having applied up to the shared cursor — and never fires while the shared cursor is still unknown (0), which would make the gate vacuous. Graduated members are queued for the send loop to emit a lane-retirement marker; a re-split cancels any not-yet-emitted marker (it would retire the NEW lane). **Lane generations:** each lane incarnation carries a generation number, because a namespace can graduate and later re-split. Cursor advances are generation-checked, so a tier loop finishing a batch from before a graduation can never fast-forward the new incarnation's cursor past tasks it hasn't sent (the classic ABA hazard). Member acked watermarks are monotonic — a stale receiver report can't rewind a persisted resume point. Member scopes reuse the multi-cursor queue framework (`queues.Scope`, `tasks.NamespacePredicate`), and the persisted reader-state codec round-trips through `queues.ToPersistenceScope`/`FromPersistenceScope`: scope 0 = overall min, 1 = shared HIGH excluding isolated namespaces, 2 = LOW, 3+ = one scope per member resuming at its applied watermark. **Scope 0 is clamped to the minimum over member resume positions**: replication task cleanup deletes strictly below `Scopes[0]` and reads no other scope, while the receiver's folded watermark cannot vouch for windows its connection has never seen (e.g. right after a reconnect, before member lanes re-form) — without the clamp, cleanup could delete a restored member's unsent window. The isolated set is capped by `maxIsolated`; restored members are kept above a lowered cap (dropping them would gap their lanes), severity resets to tier 1 on reconnect, and config inputs are clamped to sane minimums (tierCount ≥ 1 etc.) so misconfiguration cannot strand namespaces. State machine only; the stream sender is wired to it in the next PR. ## Why? This is the heart of the design, reviewable in isolation as a pure, unit-tested state machine. The per-member-lane shape is what the shared read-through buffer (first in the series) makes affordable — per-lane scans at the tip are in-memory passes — and in exchange the entire rewind/rotation protocol of the shared-cursor design disappears. ## How did you test it? - [x] built - [x] added new unit test(s) — split floors and lane scopes, member independence, the isolation cap (including slot reuse after graduation), demotion as a rate-class change capped at the deepest tier, merge-back gating on applied watermarks with cooldown and re-throttle reset (including never graduating against an unset shared cursor), retirement queueing and re-split cancellation, generation-checked and monotonic cursor advances, monotonic acked watermarks, the scope-0 cleanup clamp, config clamping, and a persistence round-trip including legacy 3-scope states ## Potential risks No production code paths reference the manager yet (wired next PR), so this PR is behaviorally inert. Merge-back remains best-effort: a calm namespace stays isolated while its lane lags the gate — harmless while calm, reset by any reconnect. The scope-0 clamp pins replication task cleanup at the slowest member lane's resume position; that retention is bounded by the lane's tier pacing and is exactly the window cleanup must not delete. 🤖 Generated with [Claude Code](https://claude.com/claude-code)", "url": "https://github.com/temporalio/temporal/pull/11304", "createdAt": "2026-07-27T12:22:34Z", "updatedAt": "2026-08-13T16:21:07Z", "timestamp": "2026-08-13T16:21:07Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "team/cgs-foundation" ], "author": "robholland", "state": "open", "assignees": [], "change": "new" } }, { "id": "event:b10e8be872e3b945b233", "signalId": "github:temporalio/temporal:pull_request:11514", "event": "changed", "observedAt": "2026-08-13T17:47:07.884300Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11514", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Define canonical Go test attempt results", "text": "Defines the package-aware canonical attempt model and its queries for failed leaves, incomplete executions, package aborts, runtime failures, process failures, and retry safety. Tests construct results directly and pin these invariants before production uses the model. Stack: depends on #11487. Scoped canonical diagnostics follow in #11488.", "url": "https://github.com/temporalio/temporal/pull/11514", "createdAt": "2026-08-12T22:10:10Z", "updatedAt": "2026-08-13T17:47:01Z", "timestamp": "2026-08-13T17:47:01Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:de688776a5ba56d73243", "signalId": "github:temporalio/temporal:pull_request:11488", "event": "changed", "observedAt": "2026-08-13T17:47:07.884300Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11488", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Scope test diagnostics to canonical results", "text": "Converts test output analysis to package-aware canonical diagnostics and failure evidence. The existing runner reaches the new implementation through a temporary compatibility adapter, so there is still one parser implementation while the production cutover remains isolated. Stack: depends on #11514. The Go test JSON recorder follows in #11515.", "url": "https://github.com/temporalio/temporal/pull/11488", "createdAt": "2026-08-11T23:31:31Z", "updatedAt": "2026-08-13T17:47:05Z", "timestamp": "2026-08-13T17:47:05Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:58080306762eeecf06a0", "signalId": "github:temporalio/temporal:pull_request:11487", "event": "changed", "observedAt": "2026-08-13T17:47:07.884300Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11487", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Separate test diagnostics and timeout parsing", "text": "Separates diagnostic parsing and timeout parsing into focused files without changing behavior. Existing comments and tests move with their implementations so the later canonical conversion is a semantic diff instead of a delete-and-add rewrite. Stack: depends on #11512. The canonical result model follows in #11514.", "url": "https://github.com/temporalio/temporal/pull/11487", "createdAt": "2026-08-11T23:31:23Z", "updatedAt": "2026-08-13T17:46:57Z", "timestamp": "2026-08-13T17:46:57Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:fdc6bcd1c4904c594c94", "signalId": "github:temporalio/temporal:pull_request:11512", "event": "changed", "observedAt": "2026-08-13T17:47:07.884300Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11512", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Use generic JUnit documents at runner boundaries", "text": "Moves testrunner report inputs, outputs, and summaries onto the shared JUnit document types. The existing reporting behavior remains unchanged behind that seam. Stack: depends on #11513. Parser separation follows in #11487.", "url": "https://github.com/temporalio/temporal/pull/11512", "createdAt": "2026-08-12T22:00:08Z", "updatedAt": "2026-08-13T17:46:52Z", "timestamp": "2026-08-13T17:46:52Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:037119f2ed389f52477b", "signalId": "github:temporalio/temporal:pull_request:11513", "event": "changed", "observedAt": "2026-08-13T17:47:07.884300Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11513", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Harden shared JUnit report IO", "text": "Strengthens shared JUnit reads and writes. Reads reject trailing XML and include the source path in errors. Writes validate counters and atomically replace the destination so interrupted writes cannot corrupt an existing report. This is the bottom of the testrunner reporting stack.", "url": "https://github.com/temporalio/temporal/pull/11513", "createdAt": "2026-08-12T22:05:45Z", "updatedAt": "2026-08-13T17:46:49Z", "timestamp": "2026-08-13T17:46:49Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:3a45434ec3a3cd1c0dcb", "signalId": "github:temporalio/temporal:pull_request:11516", "event": "changed", "observedAt": "2026-08-13T17:47:07.884300Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11516", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Plan test retries from canonical results", "text": "Moves retry selection, argument rewriting, and missing-rerun validation into a focused policy over canonical attempt results. The current runner still owns orchestration, so this PR changes the decision module without switching the reporting pipeline. Stack: depends on #11515. Canonical JUnit rendering follows in #11517.", "url": "https://github.com/temporalio/temporal/pull/11516", "createdAt": "2026-08-12T22:14:53Z", "updatedAt": "2026-08-13T17:47:09Z", "timestamp": "2026-08-13T17:47:09Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:9b64307fb9f43d2592bc", "signalId": "github:temporalio/temporal:pull_request:11515", "event": "changed", "observedAt": "2026-08-13T17:47:07.884300Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11515", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Record canonical Go test attempt results", "text": "Runs Go tests directly with JSON output and records package-aware canonical attempt results. The recorder owns event attribution, build failures, diagnostics, timeouts, console output, process state, and coverage-path handling, with focused unit and subprocess tests. Stack: depends on #11488. Retry policy follows in #11516.", "url": "https://github.com/temporalio/temporal/pull/11515", "createdAt": "2026-08-12T22:12:35Z", "updatedAt": "2026-08-13T17:47:08Z", "timestamp": "2026-08-13T17:47:08Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:fe438a468257ac5aae04", "signalId": "github:temporalio/temporal:pull_request:11543", "event": "changed", "observedAt": "2026-08-13T18:01:55.420671Z", "changedFields": [ "title", "text", "updatedAt", "labels" ], "signal": { "id": "github:temporalio/temporal:pull_request:11543", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Release gRPC resolver registrations on shutdown", "text": "## What changed? Tie process-global gRPC resolver registrations to their Fx and test owners. Resolver URLs use monotonic opaque registration IDs, test callers register cleanup directly, and matching test clients close their RPC factories during cluster shutdown. The leak test drops the corresponding host expectation. ## Why? The process-global resolver map retained cluster-owned state after shutdown. Explicit cleanup releases those references while preserving resolver availability during Fx graph construction. ## Testing - `go test -race -tags disable_grpc_modules,test_dep ./common/membership ./common/rpc/test ./tests/testcore -count=1` - `LEAK_ITERS=5 LEAK_ITERS_WARMUP=1 LEAK_GC_SETTLE_TIMEOUT=30s go test -run TestClusterShutdownLeak -count=1 -timeout 6m -tags disable_grpc_modules,,test_dep, ./tests/leakcheck/ -args -persistenceType=sql -persistenceDriver=sqlite` Stacked on #11542.", "url": "https://github.com/temporalio/temporal/pull/11543", "createdAt": "2026-08-13T15:50:19Z", "updatedAt": "2026-08-13T18:01:05Z", "timestamp": "2026-08-13T18:01:05Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "request-claude-review" ], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:f9f0c3e5d916de2dedc3", "signalId": "github:temporalio/temporal:pull_request:11551", "event": "discovered", "observedAt": "2026-08-13T18:01:55.420671Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11551", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Release OTEL logger registrations on shutdown", "text": "## What changed? Route process-global OTEL errors through lifecycle-owned logger registrations. The handler selects the newest ready registration and drops each logger reference when its Fx owner stops. The leak test drops the corresponding logger expectation. ## Why? The process-global OTEL error handler retained the server logger after shutdown. Lifecycle ownership releases that reference while supporting multiple in-process servers. ## Testing - `go test -race -tags disable_grpc_modules,test_dep ./temporal -count=1` - `LEAK_ITERS=5 LEAK_ITERS_WARMUP=1 LEAK_GC_SETTLE_TIMEOUT=30s go test -run TestClusterShutdownLeak -count=1 -timeout 6m -tags disable_grpc_modules,,test_dep, ./tests/leakcheck/ -args -persistenceType=sql -persistenceDriver=sqlite` Based on #11542.", "url": "https://github.com/temporalio/temporal/pull/11551", "createdAt": "2026-08-13T17:59:38Z", "updatedAt": "2026-08-13T17:59:38Z", "timestamp": "2026-08-13T17:59:38Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "new" } }, { "id": "event:0f6094ed336526c9c603", "signalId": "github:temporalio/temporal:pull_request:11232", "event": "discovered", "observedAt": "2026-08-13T18:01:55.420671Z", "changedFields": [], "signal": { "id": "github:temporalio/temporal:pull_request:11232", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "VLN-1574: remediate checkout-below-v7", "text": "> 🏕️ This pull request was created by [camper](https://github.com/temporalio/camper), an automated security campaign tool. ## Finding
Rulecheckout-below-v7
SeverityHIGH
Repositorytemporalio/temporal
TicketVLN-1574
## Summary - `.github/workflows/build-and-publish.yml`: Updated all `actions/checkout` uses to the required v7.0.0 commit pin. - `.github/workflows/check-release-dependencies.yml`: Updated `actions/checkout` to the required v7.0.0 commit pin. - `.github/workflows/ci-success-report.yml`: Updated `actions/checkout` to the required v7.0.0 commit pin. - `.github/workflows/docker-build-manual.yml`: Updated all `actions/checkout` uses to the required v7.0.0 commit pin. - `.github/workflows/features-integration.yml`: Updated `actions/checkout` to the required v7.0.0 commit pin. - `.github/workflows/flaky-tests-report.yml`: Updated `actions/checkout` to the required v7.0.0 commit pin. - `.github/workflows/govulncheck.yml`: Updated `actions/checkout` to the required v7.0.0 commit pin. - `.github/workflows/linters.yml`: Updated all `actions/checkout` uses to the required v7.0.0 commit pin. - `.github/workflows/optimize-test-sharding.yml`: Updated `actions/checkout` to the required v7.0.0 commit pin. - `.github/workflows/release.yml`: Updated `actions/checkout` to the required v7.0.0 commit pin. - `.github/workflows/run-single-test.yml`: Updated all `actions/checkout` uses to the required v7.0.0 commit pin. - `.github/workflows/run-tests.yml`: Updated all `actions/checkout` uses to the required v7.0.0 commit pin. ## Instructions - **Approve** to merge this fix - **Request changes** to trigger a new remediation attempt - `/camper rebase` — rebase onto the base branch - `/camper close` — close this PR without merging - `/camper retry` — regenerate the fix from scratch against the current base", "url": "https://github.com/temporalio/temporal/pull/11232", "createdAt": "2026-07-23T15:57:20Z", "updatedAt": "2026-08-13T17:58:35Z", "timestamp": "2026-08-13T17:58:35Z", "metrics": { "reactions": 0, "comments": 3 }, "labels": [], "author": "picatz", "state": "open", "assignees": [], "change": "new" } }, { "id": "event:b3cdf7392a917b864821", "signalId": "github:temporalio/temporal:pull_request:11169", "event": "changed", "observedAt": "2026-08-13T18:01:55.420671Z", "changedFields": [ "updatedAt", "labels" ], "signal": { "id": "github:temporalio/temporal:pull_request:11169", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "[CHASM] Support WithRequestID on UpdateComponent", "text": "## What changed? - `WithRequestID` now applies to `UpdateComponent`, enabling execution-level idempotency guarding via request ID. - When a request ID is passed as part of an `UpdateComponent` call (via API handler), it is persisted upon successful updateFn call. If it is already present, instead, `UpdateComponent` fails with a `FailedPrecondition`. - When a request ID is not passed in, a generated ID is still created for error tracing purposes, but it is not written to mutable state. - On transaction close, mutable state will sweep the oldest RequestIDs (with an `attach_time`) upon hitting the configured limit. - This will sweep both entries below a configurable max age, as well as past a certain hard length limit. ## Why? - Scheduler's `UpdateSchedule` and `PatchSchedule` are implemented as handlers that persist a signal in V1. V1 signals provide idempotency via their request IDs. Scheduler V2 doesn't make use of signals, so instead, it must record request IDs explicitly. - We reuse the existing map within mutable state. - We *must* fail with an explicit error (`FailedPrecondition`) instead of simply returning a zero value (as Signals would on repeated successful requests). This is because `UpdateComponent` can apply to API models that include response values (which we don't record, therefore, we can't return on subsequent calls). ## How did you test it? - [ ] built - [ ] run locally and tested manually - [ ] covered by existing tests - [x] added new unit test(s) - [ ] added new functional test(s)", "url": "https://github.com/temporalio/temporal/pull/11169", "createdAt": "2026-07-21T00:51:10Z", "updatedAt": "2026-08-13T17:51:12Z", "timestamp": "2026-08-13T17:51:12Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "reliability-2026" ], "author": "lina-temporal", "state": "open", "assignees": [ "fretz12" ], "change": "updated" } }, { "id": "event:134bc54802bca5caff9a", "signalId": "github:temporalio/temporal:pull_request:11033", "event": "changed", "observedAt": "2026-08-13T18:01:55.420671Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11033", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Return test runner orchestration outcomes", "text": "Makes test execution return an exit code and error instead of terminating inside the orchestration loop. Final artifact failures, retry-validation failures, execution errors, timeouts, and normal pass/fail outcomes are tested directly while Main remains the process-exit seam. Stack: depends on #11518 and completes the canonical Go test JSON reporting pipeline.", "url": "https://github.com/temporalio/temporal/pull/11033", "createdAt": "2026-07-13T19:38:51Z", "updatedAt": "2026-08-13T17:47:26Z", "timestamp": "2026-08-13T17:47:26Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [ "test-all-dbs", "request-claude-review" ], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:47fd968d119bc7a0f57d", "signalId": "github:temporalio/temporal:pull_request:11518", "event": "changed", "observedAt": "2026-08-13T18:01:55.420671Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11518", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Adopt canonical test reporting pipeline", "text": "Switches orchestration to canonical attempt results and JUnit rendering, then removes the legacy JUnit merger and temporary diagnostic adapter in the same PR. Intermediate and final artifacts come from one attempt history, and report writes reject inconsistent counters. Stack: depends on #11517. Explicit orchestration outcomes follow in #11033.", "url": "https://github.com/temporalio/temporal/pull/11518", "createdAt": "2026-08-12T22:21:21Z", "updatedAt": "2026-08-13T17:47:21Z", "timestamp": "2026-08-13T17:47:21Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:64c415b049b2e8c2d778", "signalId": "github:temporalio/temporal:pull_request:11517", "event": "changed", "observedAt": "2026-08-13T18:01:55.420671Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11517", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Render JUnit from canonical attempt results", "text": "Adds the pure canonical attempt-history renderer, including parent-failure suppression, diagnostics, timeouts, aborts, build errors, retry suffixes, crash reports, exact counters, and numeric durations. Integration coverage verifies the persisted JUnit shape and the downstream sharding consumer. Stack: depends on #11516. The production cutover follows in #11518.", "url": "https://github.com/temporalio/temporal/pull/11517", "createdAt": "2026-08-12T22:18:31Z", "updatedAt": "2026-08-13T17:47:17Z", "timestamp": "2026-08-13T17:47:17Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } }, { "id": "event:b9d9c3294558f9f8f431", "signalId": "github:temporalio/temporal:pull_request:11516", "event": "changed", "observedAt": "2026-08-13T18:01:55.420671Z", "changedFields": [ "updatedAt" ], "signal": { "id": "github:temporalio/temporal:pull_request:11516", "source": "github", "group": "platform-infrastructure", "project": "temporalio/temporal", "kind": "pull_request", "title": "Plan test retries from canonical results", "text": "Moves retry selection, argument rewriting, and missing-rerun validation into a focused policy over canonical attempt results. The current runner still owns orchestration, so this PR changes the decision module without switching the reporting pipeline. Stack: depends on #11515. Canonical JUnit rendering follows in #11517.", "url": "https://github.com/temporalio/temporal/pull/11516", "createdAt": "2026-08-12T22:14:53Z", "updatedAt": "2026-08-13T17:47:12Z", "timestamp": "2026-08-13T17:47:12Z", "metrics": { "reactions": 0, "comments": 0 }, "labels": [], "author": "stephanos", "state": "open", "assignees": [], "change": "updated" } } ] } }