## What changed?
Plumb executable attempt count to task attributes during task
validation/execution. Check task validator in side effect standby task
executor.
## Why?
Add a field to allow task validators to decide if task is best effort,
meaning they attempt execution a number of times before being
invalidated.
## How did you test it?
- [X] built
- [X] run locally and tested manually
- [X] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
Rename SideEffectTaskExecutor to SideEffectTaskHandler and
PureTaskExecutor to PureTaskHandler across the CHASM framework and all
library implementations (activity, callback, nexusoperation, scheduler).
Merge the separate SideEffectTaskDiscarder interface into
SideEffectTaskHandler as a required Discard method. Introduce
SideEffectTaskHandlerBase[T] which provides a default Discard returning
ErrTaskDiscarded, and PureTaskHandlerBase with an unexported marker
method — both must be embedded by implementations.
This eliminates HasDiscardHandler() from RegistrableTask and the
conditional nil check in ExecuteSideEffectDiscardTask, replacing it with
eager validation that rejects pure tasks at the call site. The discard
function is now always present on side-effect tasks, simplifying the
standby task execution path.
Also rename executor source files to tasks files in the callback and
nexusoperation packages and update receiver names from `e` to `h`
throughout.
## Why?
- The split interfaces required duplicate registration but in practice
both interfaces were implemented by a single struct.
- A base implementation is great for future proofing when more optional
methods are added.
## What changed?
Added a SideEffectDiscardHandler interface to the CHASM framework that
allows side-effect task executors to define custom discard behavior on
standby clusters. When a side-effect task has been pending on standby
past the configurable discard delay (ChasmStandbyTaskDiscardDelay), the
framework now calls HandleDiscard instead of silently discarding the
task. Implemented the handler for ActivityDispatchTask to
spill tasks to matching on standby clusters.
## Why?
On standby clusters, CHASM side-effect tasks (e.g.,
ActivityDispatchTask) were silently discarded after the discard delay.
For standalone activities, this means the activity task never gets
pushed to the standby cluster's matching queue, so workers on the
standby cluster can't pick up work even after a failover. The
HandleDiscard hook lets task executors define spillover behavior — the
activity dispatch executor uses it to push to matching on standby,
enabling faster recovery after namespace failover.
## 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)
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?
- 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?
- TaskAttributes is now passed to all CHASM executors and validators. I
decided against introducing a struct for task arguments because it's
likely that any additional bits we'd pass along to handlers would go in
`TaskAttributes`, and not some outer container (`taskWithAttributes`),
and I'd like handlers that don't need attributes to be able to simply
`_` them out.
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [] added new unit test(s)
- [ ] added new functional test(s)
---------
Co-authored-by: Stephan Behnke <stephanos@users.noreply.github.com>
## What changed?
- Fixes the interface. Method was already passing the right context
impl.
## 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)
## 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 -->
- Remove invalid tasks for CHASM component when closing transaction.
## Why?
<!-- Tell your future self why have you made these changes -->
- CHASM task processing logic
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
- Added unit test
## 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 -->
- Implement AddTask functionality for CHASM
## 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? -->
- 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 -->
- 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 -->
Added basic CHASM registry implementation.
## Why?
<!-- Tell your future self why have you made these changes -->
CHASM project.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Added new unit tests. `registry.go` has 100% coverage.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
No risks.
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
Not yet.
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
No.
## What changed?
<!-- Describe what has changed in this PR -->
- Chasm interface
## Why?
<!-- Tell your future self why have you made these changes -->
- For the new CHASM framework
## 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) -->
