Conversation
|
Important Review skippedToo many files! This PR contains 212 files, which is 62 over the limit of 150. ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (212)
You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
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 customize the tone of the review comments and chat replies.Configure the |
Package publishing
Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation. |
There was a problem hiding this comment.
💡 Codex Review
stem/packages/stem/lib/src/bootstrap/workflow_app.dart
Lines 669 to 672 in 8b6f030
StemWorkflowApp.create(..., stemApp: existingApp) and StemApp.createWorkflowApp() are documented as ways to layer workflows onto an existing task app, but shutdown() always calls app.shutdown(). In that shared-app scenario, closing the workflow wrapper will also stop the host worker and dispose any broker/backend resources owned by the original StemApp, which can take down unrelated task processing. This wrapper needs to distinguish between an app it created and one it merely borrowed.
ℹ️ 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".
| final resolvedWorkerConfig = _resolveWorkflowWorkerConfig( | ||
| workerConfig, | ||
| module: StemModule.combine(module: module, modules: modules), | ||
| tasks: tasks, | ||
| continuationQueue: continuationQueue, | ||
| executionQueue: executionQueue, | ||
| ); | ||
| final appInstance = await StemApp.fromClient( | ||
| client, |
There was a problem hiding this comment.
Fall back to
client.module in StemWorkflowApp.fromClient
When callers use the static StemWorkflowApp.fromClient(client: client) helper without re-passing a module, _resolveWorkflowWorkerConfig sees module == null and infers a subscription from only the workflow queues. That subscription is then forwarded into StemApp.fromClient, so any task handlers bundled in client.module on non-default queues are never subscribed, and workflows that enqueue those tasks will stall indefinitely. The instance helper StemClient.createWorkflowApp() already passes this.module, so this inconsistency looks accidental.
Useful? React with 👍 / 👎.
| @@ -73,6 +86,86 @@ class StemWorkflowApp { | |||
| await app.start(); | |||
There was a problem hiding this comment.
Reset startup state when
StemWorkflowApp.start() fails
start() flips _started to true before awaiting runtime.start() and app.start(), but it never clears that flag on error. If either startup step throws once (for example, a transient broker/store failure), every later start() or lazy startWorkflow() call will believe the app is already running and skip initialization, leaving the instance permanently unusable until it is rebuilt.
Useful? React with 👍 / 👎.
No description provided.