## What changed?
When a workflow is reset, `ApplyWorkflowExecutionStartedEvent`
re-registers the start-event callbacks using the reset operation's
request ID. `HandleNexusCompletion` cannot find a matching
`BufferedStart` and discards the completion. The `resetRequestID` param
is removed from `WorkflowResetter.ResetWorkflow` and the original
request ID is used. `findStartRequestID` reads the original request ID
back from `WorkflowExecutionInfo.RequestIds` by finding the
`EVENT_TYPE_WORKFLOW_EXECUTION_STARTED` entry.
## Why?
CHASM scheduler relies on callback `request_id` to match WF completions
to originating `BufferedStart` entries. When it cannot be found the
scheduler is permanently stuck with the workflow marked as still
running.
## 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 test(s)
-
`TestScheduledWorkflowDoubleReset_SchedulerSeesCompletion_{HSM,CHASM}Callbacks`:
create a schedule, trigger immediately, reset the workflow twice, signal
the completion to complete, poll `ListSchedules` until scheduler shows
`COMPLETED`.
## Potential risks
CHASM scheduler has not been enabled in production yet, the blast radius
should be minimal.
## What changed?
- Consists of the change to prevent any Pinned workflows, that may have
forgotten to have the initial CAN Behaviour as AU, from CAN'ing
infinitely.
- Also allows trampolining of a Pinned workflow onto the Unversioned if
un-versioned is the current version of the worker deployment at that
point in time. Note, the effective behaviour of the workflow would later
then be unversioned.
## Why?
- Worker-Versioning correctness.
## How did you test it?
- [x] built
- [x] run locally and tested manually
- [x] covered by existing tests
- [ ] added new unit test(s)
- [x] added new functional test(s)
## Potential risks
- Pre-existing workflows (started before this fix) have nil
TargetVersionOnStart. On the first WFT after deployment, "" !=
"build-v2" → spurious targetDeploymentVersionChanged=true. This is a
one-time false-positive regression for those Pinned workflows.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> Touches generated protobuf API surface used by internal services;
while the change is additive, mismatched proto versions across services
could cause integration/compatibility issues.
>
> **Overview**
> Adds `declined_target_version_upgrade` to
`StartWorkflowExecutionRequest` (HistoryService API) so
continue-as-new/retry chains can carry forward the SDK-declined target
deployment version and avoid pinned-workflow trampolining loops.
>
> Regenerates protobuf Go bindings, updating import/type references
across `request_response.pb.go`, and adds missing
`Marshal`/`Unmarshal`/`Size`/`Equal` helpers for the persistence
`LastNotifiedTargetVersion` message.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
0af06d0141. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
## What changed?
The counts of some top keys are persisted in task queue metadata so
they're preserved on queue movement or reloads.
## Why?
More accurate fairness
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
Set TargetVersionChanged instead of SuggestCaN when TargetVersionChanged
https://github.com/temporalio/api/pull/709
## Why?
Setting SuggestContinueAsNew=true for Pinned workflows whenever their is
a new Target Version available for that workflow causes Pinned workflows
to hit that condition much more frequently than they expect. Users who
are currently doing: if workflow_info.suggestContinueAsNew{ do
continue-as-new } in their Pinned workflow code would need to change
that code to protect themselves from running into an infinite-CaN-loop,
because the default CaN behavior for a Pinned workflow is to stay
Pinned.
We should not force users to protect themselves from such a situation.
Because upgrading on continue-as-new is opt-in, receiving the suggestion
to continue-as-new-onto-new-target-version should be opt-in as well. If
people are forced to check the new suggest-continue-as-new-reasons field
to "opt out," that is unsafe, because inevitably some people will forget
to do so or misunderstand, and then get hit by this unexpected footgun.
Much safer and still ergonomical to let upgrade-on-can be opt-in on both
fronts, as proposed here. With this change, the people who are currently
doing if workflow_info.suggestContinueAsNew{ do continue-as-new } won't
see any change in semantics, regardless of their versioning behavior.
People who consciously know that they want to do upgrade-on-can /
Trampolining will have to change their CaN options anyway, so it's easy
enough to teach them to pay attention to this new
TargetWorkerDeploymentVersionChanged flag.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [ ] added new unit test(s)
- [x] added new functional test(s)
## Potential risks
None
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> **Medium Risk**
> Touches workflow task started event generation/persistence and
versioning-related signaling, which can affect worker behavior and
history compatibility; changes are gated by dynamic config and covered
by tests.
>
> **Overview**
> Stops using `SuggestContinueAsNew` (and its reason tags) to signal
pinned workflows that a newer target worker deployment version exists,
and instead introduces an explicit
`TargetWorkerDeploymentVersionChanged` boolean on `WorkflowTaskStarted`
events and persisted `WorkflowExecutionInfo`.
>
> Adds namespace dynamic config `EnableSendTargetVersionChanged`
(default on) and a new metric `workflow_target_version_changed_count`
emitted when this flag is set; updates the workflow task state machine,
mutable state plumbing/mocks, proto/pb persistence, and functional tests
accordingly. Also bumps `go.temporal.io/api` to pick up the new event
attribute.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
3886491826. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
## What changed?
Implement detached component as a Field option and Registrable Component
option.
Add detached boolean value to ComponentAttributes persistence proto
definition.
## Why?
Allow detached components to continue updates and task execution even if
parent node lifecycle is closed.
## 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)
This reverts commit 58449b9d80.
## What changed?
This reverts Nexus schedule to start and start to close timeouts (with
fixes) (#9033)
## Why?
Causes failures in nightly pipeline
## How did you test it?
- [X] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
When buffered events are applied, like when applying signals after
workflow task failures occur, preserve the workflow task attempt so the
`TemporalReportedProblems` search attribute is still properly added.
## Why?
Without this change the `TemporalReportedProblems` search attribute will
never be added if a workflow is consistently queried.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [X] added new functional test(s)
## Potential risks
Minimal, this adds a new int to the workflow task execution, but it's
only used in one place.
## What changed?
Reapplied #9010.
The original PR that introduced these timeouts did not populate the
operation-timeout header or set the call context timeout correctly. This
PR fixes the logic.
## Overview
This commit implements two new granular timeout types for Nexus
operations, allowing callers to have fine-grained control over different
phases of operation execution:
- **Schedule-to-Start Timeout**: Maximum time to wait for an operation
to be started (or completed if synchronous) by the handler
- **Start-to-Close Timeout**: Maximum time to wait for an asynchronous
operation to complete after it has been started
These timeouts complement the existing **Schedule-to-Close Timeout** to
provide better control and diagnostics for Nexus operation execution.
See the corresponding API PR:
https://github.com/temporalio/api/pull/695.
## What changed?
Add a new dynamic config for Auto Enabling fairness and priority if we
see the relevant tasks coming in.
## Why?
Seamlessly start to transition users who start using the fields over to
the new code path.
## 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
Due to storing this in the userdata we are using that interface a bit
more, we also need to change the initialization such that we start it
before being able to substantiate the defaultQ, this change in
initialization might have unintended side effects that I'm not currently
seeing.
## What changed?
Keep the total number and the size of the external payloads per the
workflow execution
## Why?
We are working on building the support for external payloads in SDK,
which are stored outside of Temporal. We'd like to be able to show the
total size and the number of external payloads in the given workflow
execution.
## 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)
## Potential risks
N/A
## What changed?
Give the option to upgrade-on-Continue-as-New with a continue-as-new
option.
Ensure that Pinned Overrides are inherited across the entire
continue-as-new chain, regardless of the initial versioning behavior of
the continue-as-new.
## Why?
To unlock "Trampolining"
## 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)
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> Introduces explicit Continue-as-New tracking and version-targeting
across APIs and server internals.
>
> - Protos: add `target_deployment_version` to
`RecordWorkflowTaskStartedRequest`; add repeated
`workflow_task_suggest_continue_as_new_reasons` to persistence
`WorkflowExecutionInfo`; regenerate bindings and enum imports
> - History: plumb `target_deployment_version` through
`AddWorkflowTaskStartedEvent`; include `suggest_continue_as_new_reasons`
in `WorkflowTaskStarted` events; choose non-nil `VersioningOverride`
when starting executions (user or inherited)
> - Metrics: remove `workflow_update_continue_as_new_suggestions`; add
`workflow_continue_as_new_count` and
`workflow_suggest_continue_as_new_count`; introduce tags
`continue_as_new_versioning_behavior` and per-reason suggest flags; tag
helpers added
> - Interfaces/tests: extend
`MutableState.Add/ApplyWorkflowTaskStartedEvent` and `WorkflowTaskInfo`
with suggest reasons; update call sites and tests; update
`common/util_test.go` scan; bump `go.temporal.io/api`
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
849687bd0c. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
Added standalone activity Chasm tasks. Added handling of start activity
and e2e implementation of standalone activity start execution with
existing services. Updated protos related to standalone activities.
The Chasm tasks are needed to kick off standalone activity execution via
the existing services. Proto changes needed to so that the component ref
can be passed and handled via service stack.
- [X] built
- [X] run locally and tested manually
- [X] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
---------
Co-authored-by: Roey Berman <roey.berman@gmail.com>
Co-authored-by: Dan Davison <dan.davison@temporal.io>
## What changed?
Remove unused code about versioning deprecated pre-release APIs (only
v0.3.0).
## Why?
The code is not used by the current implementation. The APIs previously
referring to the code has been returning the following error for the
last 6+ months:
```
Deployments are deprecated and no longer supported, use Worker Deployments instead
```
## 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
None
## What changed?
- Use archetypeID everywhere in history service and pass them to
persistence
## Why?
- Required for separate ID space work.
## 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)
## What changed?
- Rename Entity to Execution
## Why?
- We agreed on the new naming.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## What changed?
- Add a new flag that controls whether clusters setup replication
streams to each other
- Feature flag to gate the new flag for compatibility
- Functional test to vet the changes
## Why?
Optimization to avoid excessive network activity when we only want
namespace replication.
## How did you test it?
- [x] built
- [x] run locally and tested manually
- [x] covered by existing tests
- [ ] added new unit test(s)
- [x] added new functional test(s)
---------
Co-authored-by: Claude <noreply@anthropic.com>
## What changed?
**Note**: This depends on https://github.com/temporalio/api/pull/653.
Sending it for some early feedback.
- Made changes to `WorkflowPauseInfo` (in WorkflowExecutionInfo).
Reusing unused proto fields.
- Added mutablestate.IsWorkflowExecutionPaused()
- Added mutablestate.AddWorkflowExecutionPausedEvent()
## Why?
- These changes are needed to implement pause/unpause features.
## 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)
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> Adds workflow-level pause/unpause with new `WorkflowPauseInfo` fields,
client endpoints, history event handling, state/status validation for
`PAUSED`, and tests; removes activity-level pause info.
>
> - **Protocol/API**:
> - Redefine `persistence.v1.WorkflowPauseInfo` to `{pause_time,
identity, reason, request_id}`; remove `ActivityPauseInfo` and related
helpers.
> - Bump dependency `go.temporal.io/api` and adjust generated code
indexes.
> - Update RPC metadata, redirection maps, quotas, and log tags for
`PauseWorkflowExecution`/`UnpauseWorkflowExecution`.
> - **Frontend Clients**:
> - Add `PauseWorkflowExecution` and `UnpauseWorkflowExecution` to
`client_impl`, `metric_client`, `retryable_client`, and mocks.
> - **History/State**:
> - Add `WorkflowExecutionPaused` event creation
(`Create/Add...PausedEvent`) with buffering rules (paused allowed to
buffer; unpaused not buffered).
> - Implement `ApplyWorkflowExecutionPausedEvent`: set status `PAUSED`,
populate `executionInfo.PauseInfo`, invalidate pending activities and
workflow task via stamps.
> - Rebuilder applies paused event; state transition validation supports
`PAUSED` across CREATED/RUNNING/ZOMBIE.
> - **Validation/Tests**:
> - Allow `WORKFLOW_EXECUTION_STATUS_PAUSED` in validators; expand unit
tests for create/update state/status and paused behavior.
> - **Tooling**:
> - `buf.yaml` breaking ignore for `executions.proto`.
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
951c9c4a53. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
## What changed?
- Introduce typeID for registered CHASM components and tasks
- In longer term the relationship between component/task name and ID
should be persisted (similar to namespace)
## Why?
- Store less data
- Decouple user visible name from internal implementation, making it
possible in the future to rename components/tasks
- Required for separate ID space work, where archetype information needs
to be stored in all history tasks as well.
## 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)
## What changed?
- This PR adds revision number mechanics to handle task dispatch
inconsistencies that could arise since our versioning API's are becoming
eventually-consistent.
## Why?
- Making our versioning API's eventually consistent.
## 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
- There are risks but they are gated by a dynamic config.
<!-- CURSOR_SUMMARY -->
---
> [!NOTE]
> Adds revision-number semantics to task dispatch/versioning and
introduces a new per-deployment TQ user-data schema, updating APIs,
persistence, and server logic (DC-gated) with comprehensive tests.
>
> - **APIs (proto changes)**:
> - Add `revision_number` to `taskqueue.v1.TaskVersionDirective` and
propagate `task_dispatch_revision_number` in History
`Record*TaskStarted` requests.
> - Matching `SyncDeploymentUserDataRequest`: new fields
`deployment_name`, `update_routing_config`, `upsert_versions_data`,
`forget_versions`; response includes `routing_config_changed`. Deprecate
old `update_version_data`/`forget_version` oneof.
> - Deployment API: add `WorkerDeploymentVersionData`; mark
`DeploymentVersionData` deprecated where applicable.
> - **Persistence (task queue user data)**:
> - Extend `DeploymentData` with `deployments_data` (map of deployment →
`WorkerDeploymentData` holding `RoutingConfig` and per-build version
data). Deprecate legacy `versions` and `unversioned_ramp_data` fields.
> - **Server logic**:
> - Matching/History: compute target version using revision numbers;
start workflow deployment transitions using revision-aware decisions;
support mixed old/new schemas when calculating current/ramping.
> - Matching: new helpers to migrate/clean old-format entries, apply
routing-config updates atomically, and prevent query blackholes using
status.
> - Task dispatch carries and records revision number; internal task
struct/plumbing updated.
> - **Dynamic config**:
> - Add `system.useRevisionNumberForWorkerVersioning` (plumbed through
History/Matching) to gate new behavior.
> - **Tests**:
> - Add/expand unit and functional tests covering new schema,
routing-config updates, revision-number behavior, and propagation.
> - **Misc**:
> - Describe/Stats paths updated to read both schemas; minor build/deps
update (api-go replace).
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
e84f484506. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
---------
Co-authored-by: ShahabT <shahab.tajik@temporal.io>
## What changed?
- added "stamp" field to both workflow execution and transfer/timer
workflow task.
- bumping stamp up when rescheduling a workflow task
- making sure stamp is current when dequeuing workflow task
- making sure stamp is current when recoding workflow start
## Why?
Activity tasks already have the "stamp" mechanism. This is the same idea
for workflow tasks.
It essentially provides a unified approach to invalidate activity and
workflow tasks when rescheduling them.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)
I intend to write more tests for when I'm implementing the update
priority feature. It's much easier to setup and test than versioning
overrides (which are the only way right now to trigger a stamp
increase).
## What changed?
Allow draining backlog from the other table when moving from tasks v1 to
v2 and back (i.e. classic to fairness-enabled).
Exiting draining mode when draining is complete is not implemented yet.
## Why?
To allow migrating to fairness without losing tasks.
## How did you test it?
- [x] added new functional test(s)
## Potential risks
We need to get the rangeid lock on both tables when migrating, which
slows down initialization. This is only the first time and while
migration is active, after the old tasks are drained then we won't need
to lock the old table. That part isn't implemented yet, so this is off
by default.
## What changed?
* The Callbacks component now detects Nexus URLs of the form
`temporal://internal/chasm`, which are routed to CHASM components
through a new `ChasmInvocation`.
* CHASM routing information is serialized into a header, the URL is left
opaque.
* A new CHASM interface has been added, `chasm.NexusCompletionHandler`,
which components can implement to receive Nexus callbacks.
* A CHASM helper method, `GetNexusCallback`, has been added that returns
a `Callback` protobuf routing to the given component.
* The frontend's callback argument validator has been patched to allow
"temporal" schemes unconditionally. Scheduler starts workflows through
the frontend, in order to be counted by metering, and so frontend must
allow requests with internal-facing callbacks.
* I believe @chaptersix 's changes also touch this area, we may not need
my interim patch there.
## Why?
* CHASM Scheduler needs to find out about workflow completions, and we
want to do that with Nexus completion callbacks.
## 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)
## Potential risks
* The funkiness is in the frontend handler - see the TODO. I don't think
it presents a security risk, since a customer would only be able to
forge completions within their own namespace (since this validation
takes place within `StartWorkflowExecution`'s frontend flow). But it
would be nice to validate that it was only coming from internal pods.
---------
Co-authored-by: Roey Berman <roey@temporal.io>
## What changed?
1. Impl to write IsCloseTransferTaskAcked and IsForceReplication flags
on replication stream.
2. Impl for a replication stream interceptor, which fully intercepts
client and server and stores calls in-memory for us to assert against.
Also writes to log files so we can reason about/follow logs without
touching server code (this impl does not immediately log to file for
perf reasons).
3. Accompanying tests (unit and functional)
## Why?
This is part of a larger change to optimize passive task processing by
no-oping side-effects of task processing depending on if we can deem
that the task has already been processed on the parent. Will expand
further in the next 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)
- [x] added new functional test(s)
`michaely520 ~/projects/temporal % go test -v -tags test_dep ./tests/xdc
-run
TestStreamBasedReplicationTestSuite/EnableTransitionHistory/TestCloseTransferTaskAckedReplication
-timeout 10m -count=1`
## What changed?
Add a new search attribute `TemporalReportedProblems` when a workflow
task fails or timeouts N consecutive times
## Why?
Enables users to easily discover workflows that are not making progress.
After a workflow task fails or times out N consecutive times a Search
Attribute, `TemporalReportedProblems` a `KeywordList`, will be added
with two entries, a `cause` and a `category`. These search attributes
will be queryable by users with queries like:
* `TemporalReportedProblems IS NOT NULL`
* `TemporalReportedProblems IN ('category=WorkflowTaskFailed')` or
`TemporalReportedProblems IN ('category=WorkflowTaskTimedout')`
* `'TemporalReportedProblems IN ("cause=UnhandledApplicationFailure")'
OR 'TemporalReportedProblems IN ("cause=ScheduleToCloseTimeout")'`
## How did you test it?
- [ ] built
- [X] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [X] added new functional test(s)
- [x] added new xdc test(s)
## Potential risks
Flapping _could_ happen with this change, but is unlikely. There's a
possibility of overloading the visibility system, but these changes are
protected with a dynamic config.
---------
Co-authored-by: Roey Berman <roey@temporal.io>
## What changed?
use activity start event version to verify SDK's activity update request
## Why?
The version in activity task token is the version when the activity task
is started. However, when checking sdk activity requests, server uses
activity info's version which is the last write version. If there is a
failover, ai.version might be updated to new active's failover version.
The sdk activity request check will fail.
## 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
## What changed?
- Minimized the # of chasm component path encoding & decoding
- Cache encoded path for a component.
- Restructure logical & physically task generation logic to reduce # of
tree scans.
## Why?
- Avoid unnecessary path encoding/decoding
- Simplify code
## 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)
## What changed?
- Move chasm test payload store proto def to chasm package
## Why?
- Follow the new convention we set up for chasm components
## 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)
## What changed?
Adding proto changes to capture pause information. This contains 2 main
objects:
1. WorkflowPauseInfo: A container to capture pause information in a
given workflow. Adding this for future compatibility. The intention is
to use this container for other workflow level pause information like
timeouts, signals, child workflows etc.
2. ActivityPauseInfo: A container to capture pause information for a
given activity type. Since individual activity types can be paused, we
need to capture the pause state, identity & reason for better debugging.
Note: Sending just the proto changes so that we can work on
implementation in parallel.
## Why?
To implement pause activity and eventually pause workflow feature. Need
this space to save the state information.
## How did you test it?
- [x] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## Potential risks
N/A
---------
Co-authored-by: Roey Berman <roey@temporal.io>
## What changed?
- Add CHASM built-in visibility component and task processing logic
## Why?
- Basic chasm visibility work for unblocking Scheduler migration.
## 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)
## What changed?
- Remove unused CloseTime field in delete visibility logic
## Why?
- Clean up code
## 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)
## What changed?
- Add FairLevel to some protos.
- Implement pass handling in task store v2.
- Remove TTLs from task store v2.
- Add some error checking to prevent misuse.
- Add support for using LIMIT in the GetTasks query.
- Rename some things.
## Why?
Start implementing matching task fairness.
## How did you test it?
- [x] built
- [x] covered by existing tests
## What changed?
+ Introduced a new Update TaskQueueConfigApi.
+ Implemented the corresponding handlers in the frontend service and the
matching service.
+ Persistence of TaskQueueConfig from the UpdateTaskQueueConfigApi.
+ Return the config response as part of the DescribeTaskQueue api.
## Why?
+ This is the first part of the UpdateTaskQueueConfig Implementation.
+ Goal is to persist the TaskQueueConfig and handle nil values in the
update request.
+ Next steps would be to attach the corresponding rate limiters with the
persisted configs.
## How did you test it?
- [x] built
- [x] run locally and tested manually
## What changed?
- Add a test payload store implementation
- Setup CHASM functional test suite
## Why?
- Have E2E coverage for CHASM framework
## How did you test it?
- [x] built
- [x] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [x] added new functional test(s)
## What changed?
Add SuccessorRunId in ms and use that to get new run when generating
sync state result.
## Why?
If the workflow is terminated because of
`WORKFLOW_ID_CONFLICT_POLICY_TERMINATE_EXISTING`, NewExecutionRunId is
not set in the mutable state. In this case, Sync state is not able to
get the new run info. The new run will not be replicated to the target
cluster.
## 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
## What changed?
- Properly Implement Ref() method and populate all necessary fields
- Refactor ComponentRef and related methods
## Why?
- CHASM workstream
## 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)
## What changed?
Change version string to a struct
- The worker management workflows have not changed in this PR, instead,
the new inputs are converted to the old inputs when they come in, and
the responses are filled in to have both the old and new fields
- Only the new way to specify version transition is stored in MS, but
both are populated on read
- Change VersioningOverride so that we can safely specify multiple types
of pinned override in the future
- Store only the new fields, return the old fields on read.
## Why?
So that we don't have to rely on the string representation of a version,
and to make way for more types of PINNED.
## How did you test it?
- [x] built
- [x] run locally and tested manually
- [x] covered by existing tests
- [x] added new unit test(s)
- [x] added new functional test(s)
## Potential risks
This could theoretically break how workflow execution versioning info
and old versioning overrides are handled when they are read, how
pinned-ness is calculated, etc. The functional tests in
versioning_3_test.go test for this, and they revealed mistakes I had
made, which means we know those code paths are executed.
I did not change anything in the Deployment Manager workflows, so this
PR does not risk breaking those workflows via an incompatible change.
Tests in DeploymentVersionSuite guard against the risk of older SDK
users not seeing the fields they expect.
## What changed?
<!-- Describe what has changed in this PR -->
Add a targetCluster field to the replication task and propagate it from
the failover workflow all the way to the task generation logic. Include
this parameter in the SyncWorkflowStateTask. Finally, update the stream
sender to check this parameter and only send the task if target ==
targetCluster; otherwise, skip transmission.
## Why?
<!-- Tell your future self why have you made these changes -->
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
* Add "reset_activity" and "reset_heartbeat" flags to the activity info
* send "reset_requested" flag to the worker in response to heartbeat
request
* if "reset_heartbeat" flag was set - reset heartbeats for new attempt
only
* remove "reset_activity" and "reset_heartbeat" flags for the new
attempt
Corresponding API PR: https://github.com/temporalio/api/pull/578
## Why?
<!-- Tell your future self why have you made these changes -->
To notify the workers/SDK that reset happens.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Running existing tests.
Note: replication in the next PR
## What changed?
<!-- Describe what has changed in this PR -->
Changes are mainly on replication side:
- Update mutable state GetCurrentVersion/StartVersion/CloseVersion()
methods
- Update mutable state executionInfo.LastEventTaskID. and make sure it's
updated even if a transition doesn't generate any events.
- Update state based replication logic to handle no event case.
## Why?
<!-- Tell your future self why have you made these changes -->
- CHASM runs may not have events at all. We need to make sure logic
continue to work in that case.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
- Existing tests
- Will have functional tests later when CHASM is ready to ensure things
can work e2e.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
Remove license header from every file. Because it is really hard to
follow in this PR here is the summary:
1. License header is removed from all `.go` and `.proto` files
:fireworks::fireworks:🎆.
2. `LICENSE` file in the root directory has only Temporal and Uber
copyrights.
3. 5 other `LICENSE` files added to the packages which have copyrights
different from Temporal and Uber: Datadog, Xargin, "Mat Ryer, Tyler
Bunnell and contributors".
4. `license_file` flag is removed from all code generation tools.
5. `copyright_file` flag is removed from `go:generate mockgen`
directive.
6. All copyright related targets are removed from `Makefile`.
7. Updated Temporal copyright year to 2025 everywhere.
## Why?
<!-- Tell your future self why have you made these changes -->
I double checked with legal department that it is not needed to have
license header in every file. One file per repo is enough. I put all
copyrights to the root `LICENSE` file and removed header from all other
files. Also updated tools and `Makefile`.
## What changed?
<!-- Describe what has changed in this PR -->
Handle links in Nexus callbacks.
Links in `StartWorkflowRequest` will dedup the links that are also in
Nexus callbacks.
## Why?
<!-- Tell your future self why have you made these changes -->
Nexus links are gonna be associated with the Nexus callbacks, and they
will follow the callback when there is a continue-as-new or retries.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Added tests
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
Store request ID in `CallbackInfo` so we can generate Nexus completion
link based on request ID
## Why?
<!-- Tell your future self why have you made these changes -->
Generate well-defined links for attached callback requests.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
Add event ID to `RequestIDInfo`.
Also added `RequestIdInfos` to `DescribeWorkflowExecutionResponse`.
## Why?
<!-- Tell your future self why have you made these changes -->
Be to able to find which event was added by the give request ID.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
- Generate physical tasks
- Carryover cluster local task status during replication
## Why?
<!-- Tell your future self why have you made these changes -->
- CHASM task support
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
- Added unit tests
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
* Add proto messages for PauseInfo to ActivityInfo (basically the same
as in API)
* Populate PauseInfo for activities paused manually
* Populate PauseInfo for activities paused by the rules
* Populate PauseInfo in DescribeWorkflow response
* Add tests (mostly functional).
## Why?
<!-- Tell your future self why have you made these changes -->
Part of the activity commands work. If activity is paused - users should
be able to get quick answer to "Who/When/Why" questons.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Add functional tests
## What changed?
<!-- Describe what has changed in this PR -->
Add special handling for new workflow replication
## Why?
<!-- Tell your future self why have you made these changes -->
To reduce passive side loadmutablestate not found attempt
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
unit test
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
no risk
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
n/a
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
no
---------
Co-authored-by: Yichao Yang <yichao@temporal.io>
