Use workflow init from samples - #143
Conversation
Resolve conflicts in favor of main: - ClusterManagerWorkflow already adopted @workflow.init on main. - The message_passing/introduction comment this branch fixed no longer exists after that sample was refactored. - poetry.lock/pyproject.toml: the repo moved from poetry to uv, and the temporary local-path SDK dependency is unnecessary now that workflow init is in a released SDK. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Workflow init lets a workflow's constructor receive the workflow arguments and run before any signal, query, or update handler. EntityBedrockWorkflow takes arguments and has signal handlers that mutate the same state those arguments initialize, so it should demonstrate the best practice. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Status update: I've brought this branch up to date with Most of this PR landed through other paths while it sat, so the diff is now a single file. Already on
Dropped:
Remaining: Verified with ruff, mypy, and an end-to-end run against the time-skipping test environment with a stubbed Bedrock activity, sending a signal alongside a pre-populated Note the PR description above is now stale — it describes the broader multi-sample scope and references |
What was changed
Workflow Init is a brand new feature.
Let's show people best practices for each sample that uses a signal or update handler and receives workflow arguments.
Why?
These changes make sure these workflows are initialized before signal or update handlers are run.
Checklist
Closes
How was this tested:
Automated:
poetry run pytest workflow_test.pyManual:
Follow instructions in
bedrock/entity/README.mdand
message_passing/safe_message_handlers/README.md