Improve workflow DX, manifests, and generated APIs#20
Conversation
|
Important Review skippedToo many files! This PR contains 265 files, which is 115 over the limit of 150. ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (265)
You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Tip You can get early access to new features in CodeRabbit.Enable the |
Package publishing
Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: afc51c1f1f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| buffer.writeln(' static final PayloadCodec<$typeCode> $symbol ='); | ||
| buffer.writeln(' PayloadCodec<$typeCode>('); | ||
| buffer.writeln(' encode: (value) => value.toJson(),'); | ||
| buffer.writeln( | ||
| ' decode: (payload) => $typeCode.fromJson(' |
There was a problem hiding this comment.
Reject or unwrap nullable DTO types in generated codecs
_payloadCodecTypeCode accepts codec-backed DTOs even when the annotated type is nullable, so this emitter will generate PayloadCodec<Foo?> plus value.toJson() and Foo?.fromJson(...). That is invalid Dart, which means any annotated task/workflow parameter, result, or checkpoint that uses an optional DTO will fail codegen/builds instead of producing a usable helper.
Useful? React with 👍 / 👎.
| return StemWorkflowApp.create( | ||
| module: module, | ||
| workflows: workflows, | ||
| flows: flows, | ||
| scripts: scripts, |
There was a problem hiding this comment.
Forward task registrations in
StemWorkflowApp.fromClient
This factory now accepts a tasks iterable, but the StemWorkflowApp.create(...) call never passes it through. In the fromClient path, any workflow that depends on handlers supplied via tasks: will start without those handlers in the shared registry, so step-enqueued work can be dead-lettered as an unregistered task even though the caller provided the handler list.
Useful? React with 👍 / 👎.
Summary
This branch overhauls Stem's workflow/task DX and related docs.
It does four main things:
tasks:and generated bundles the default wiring path instead of manual registriesHighlights
Workflow runtime and DX
StemModule, typedWorkflowRef/WorkflowStartCall, typed task definition helpers, and generated bundle-first builder outputtasks:-first wiring acrossStem,Worker,Canvas, andStemWorkflowAppExamples and docs
.siteand refresh READMEs/snippets to match the current APIsAdapters and stores
Compatibility and safety
SimpleTaskRegistryas a deprecated compatibility aliasTesting
Ran targeted validation across the changed areas, including:
dart testforpackages/stem,packages/stem_builder,packages/stem_memory,packages/stem_sqlite,packages/stem_redis, andpackages/stem_postgresworkflow/store/bootstrap suitesdart analyzeon the changed package setsnpm --prefix .site run buildNotes
master.