ShivamandGitHub b23064f27b Pass deployment state and version state in forceCAN signals (#9100) ...

## What changed?
- WISOTT

## Why?
- Operational readiness. There could be a world where we want to "reset"
a user's workflow state given that these workflows CAN so frequently.

## 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
- None

---

> [!NOTE]
> Introduces optional state override when force-continuing-as-new.
> 
> - New proto messages `ForceCANDeploymentSignalArgs` and
`ForceCANVersionSignalArgs` with `override_state` fields; generated
helper/pb code updated
> - Deployment and Version workflows now receive `forceCAN` signals with
args and, if provided, apply `override_state` before continue-as-new
> - Added tests verifying override is honored (e.g., manager identity
and metadata) after continue-as-new
> 
> <sup>Written by [Cursor
Bugbot]() for commit
1fd847da1cb7f4520984af3b28ae6ad52148da29. This will update automatically
on new commits. Configure
[here]().</sup>

2026-01-28 17:23:54 -05:00

..

message.proto

Pass deployment state and version state in forceCAN signals (#9100)

2026-01-28 17:23:54 -05:00