Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Summary by CodeRabbit
WalkthroughRemoved monitor/polling-based continue-as-new handling; added an upfront continue-as-new check before executing activities in both Python and TypeScript workflows, deleted the Changes
Sequence DiagramsequenceDiagram
participant WF as ScriptWorkflow
participant Info as WorkflowInfo
participant Executor as TaskExecutor
participant Activity as ActivityHandler
rect rgba(100,200,100,0.5)
Note over WF,Activity: Upfront continue-as-new check, direct task execution
end
WF->>Info: workflowInfo()
Info-->>WF: continueAsNewSuggested?
alt suggested
WF->>WF: continueAsNew(WorkflowRequest with original input)
else not suggested
WF->>Executor: executeTask(activity, input, ctx)
Executor->>Activity: run activity
Activity-->>Executor: result
Executor-->>WF: [result]
WF->>WF: propagate [result] and ctx to onComplete/child tasks
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Disabled knowledge base sources:
📒 Files selected for processing (2)
🧰 Additional context used📓 Path-based instructions (5)**/*.{ts,tsx,js,jsx}📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
**/*.{ts,tsx}📄 CodeRabbit inference engine (AGENTS.md)
Files:
**/ts-moose-lib/src/**/*.ts⚙️ CodeRabbit configuration file
Files:
**/*.py📄 CodeRabbit inference engine (AGENTS.md)
Files:
**/framework-cli/src/**⚙️ CodeRabbit configuration file
Files:
🧠 Learnings (5)📓 Common learnings📚 Learning: 2026-01-26T00:56:27.011ZApplied to files:
📚 Learning: 2026-01-15T19:41:53.563ZApplied to files:
📚 Learning: 2026-01-15T19:41:53.563ZApplied to files:
📚 Learning: 2026-01-26T01:14:58.758ZApplied to files:
🧬 Code graph analysis (1)apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py (2)
🪛 Ruff (0.14.14)apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py[warning] 6-6: (UP035) [warning] 6-6: (UP035) [warning] 147-147: Consider moving this statement to an (TRY300) ⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
🔇 Additional comments (7)
✏️ Tip: You can disable this entire section by setting 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Fix all issues with AI agents
In
`@apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py`:
- Around line 147-150: The docstring for _execute_single_activity is fine but
should explicitly document the special-case mapping where timeout="never" is
treated as a very large schedule timeout; update the _execute_single_activity
docstring to note that passing timeout="never" results in the workflow using a
large-schedule-timeout behavior (rather than infinite blocking), mention any
implications for retries or scheduling semantics, and keep it short and adjacent
to the existing """Execute a single activity.""" description so readers of the
Workflow._execute_single_activity method see the timeout="never" behavior
immediately.
- Line 143: The except block currently binds an unused exception variable via
"except Exception as e:" which triggers Ruff F841; change the handler to either
drop the binding ("except Exception:") or rename it to a prefixed unused name
("except Exception as _e:") in workflow.py so the unused-variable warning is
resolved while preserving the same exception handling behavior in that
try/except block.
- Line 6: The import line currently uses deprecated typing aliases (from typing
import Any, Dict, List, Optional); change it to only import Any and Optional
(from typing import Any, Optional) and replace all occurrences of the
annotations using Dict and List in this module (e.g., function signatures,
return types, and variable annotations in workflow.py) with the built-in
lowercase types dict and list (e.g., Dict[str, Any] -> dict[str, Any], List[int]
-> list[int]); ensure type hints throughout the file (including in any functions
or classes that reference Dict or List) are updated accordingly and that
Optional/Any remain from typing.
In `@packages/ts-moose-lib/src/scripts/workflow.ts`:
- Around line 111-128: The continueAsNew call currently only sends the request
object and drops the current inputData so resumed workflows receive undefined;
update the continueAsNew invocation inside the workflow (near executeTask/
workflowInfo/ task) to pass inputData as the second argument (same shape the
Python version uses) so the restarted workflow receives the original input;
ensure the payload type matches the continueAsNew API signature and adjust any
typing or serialization if needed.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.pypackages/ts-moose-lib/src/scripts/workflow.ts
🧰 Additional context used
📓 Path-based instructions (5)
**/*.py
📄 CodeRabbit inference engine (AGENTS.md)
**/*.py: Follow PEP 8 style guide in Python; use snake_case for functions/variables, PascalCase for classes, UPPER_SNAKE_CASE for constants
Format Python code with Black using line-length 88; auto-formats on commit via Husky + lint-staged
Use type hints for function signatures and public APIs in Python
Files:
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
**/framework-cli/src/**
⚙️ CodeRabbit configuration file
**/framework-cli/src/**: When reviewing changes to Moose CLI:
- Check if any user-facing changes were made (commands, flags, configs, apis, etc)
- If yes, verify the documentation for THAT SPECIFIC feature is updated in apps/framework-docs-v2/content
- If docs for that feature doesn't exist yet, it should be added. If the change removes public apis, the documentation for those should also be removed. Changing unrelated docs doesn't satisfy this requirement.
- In addition to reviewing for docs discrepancies, you should also review the code as per usual guidelines.
Files:
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Run linting checks before submitting PRs for TypeScript/JavaScript code
**/*.{ts,tsx,js,jsx}: Group imports by external dependencies, internal modules, and types; use named exports from barrel files (index.ts)
Use camelCase for variables and functions, PascalCase for types/classes/components, UPPER_SNAKE_CASE for constants in TypeScript/JavaScript
Prefix unused variables with underscore (e.g.,_unusedParam) to bypass linting errors in TypeScript/JavaScript
Format TypeScript/JavaScript code with Prettier usingexperimentalTernaries: true; auto-formats on commit via Husky + lint-staged
Files:
packages/ts-moose-lib/src/scripts/workflow.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Prefer interfaces for objects, types for unions/intersections in TypeScript; explicit return types on public APIs
Files:
packages/ts-moose-lib/src/scripts/workflow.ts
**/ts-moose-lib/src/**/*.ts
⚙️ CodeRabbit configuration file
**/ts-moose-lib/src/**/*.ts: When reviewing changes to typescript moose lib:
- Check if any public apis were changed (class, method, type, config, etc).
- If yes, verify the documentation for THAT SPECIFIC feature is updated in apps/framework-docs-v2/content.
- If docs for that feature doesn't exist yet, it should be added. If the change removes public apis, the documentation for those should also be removed. Changing unrelated docs doesn't satisfy this requirement.
- In addition to reviewing for docs discrepancies, you should also review the code as per usual guidelines.
Files:
packages/ts-moose-lib/src/scripts/workflow.ts
🧠 Learnings (3)
📓 Common learnings
Learnt from: DatGuyJonathan
Repo: 514-labs/moosestack PR: 3400
File: apps/framework-cli/src/framework/core/infrastructure_map.rs:1238-1298
Timestamp: 2026-01-26T00:56:27.011Z
Learning: Repo 514-labs/moosestack — Workflows: The CLI’s workflow diff is intended to detect only Temporal schedule–affecting changes. In apps/framework-cli/src/framework/core/infrastructure_map.rs, workflows_config_equal should compare schedule, retries, and timeout only; it must not include tasks. Task code/config changes are picked up automatically when the orchestration worker restarts and should not trigger a WorkflowChange.
📚 Learning: 2026-01-26T00:56:27.011Z
Learnt from: DatGuyJonathan
Repo: 514-labs/moosestack PR: 3400
File: apps/framework-cli/src/framework/core/infrastructure_map.rs:1238-1298
Timestamp: 2026-01-26T00:56:27.011Z
Learning: Repo 514-labs/moosestack — Workflows: The CLI’s workflow diff is intended to detect only Temporal schedule–affecting changes. In apps/framework-cli/src/framework/core/infrastructure_map.rs, workflows_config_equal should compare schedule, retries, and timeout only; it must not include tasks. Task code/config changes are picked up automatically when the orchestration worker restarts and should not trigger a WorkflowChange.
Applied to files:
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.pypackages/ts-moose-lib/src/scripts/workflow.ts
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/workflows/*-sync.ts : Scheduled sync workflows should use Cron schedule expressions (e.g., '0 * * * *' for hourly, '*/5 * * * *' for every 5 minutes), fetch from external APIs using Bearer token authorization, and return a SyncResult object with synced count and errors
Applied to files:
packages/ts-moose-lib/src/scripts/workflow.ts
🧬 Code graph analysis (2)
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py (3)
packages/py-moose-lib/moose_lib/dmv2/workflow.py (2)
Workflow(132-189)Task(56-112)packages/ts-moose-lib/src/dmv2/sdk/workflow.ts (2)
Workflow(153-238)Task(61-103)apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/types.py (1)
WorkflowStepResult(5-7)
packages/ts-moose-lib/src/scripts/workflow.ts (1)
packages/ts-moose-lib/src/scripts/activity.ts (1)
executeTask(73-169)
🪛 Ruff (0.14.14)
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
[warning] 6-6: typing.Dict is deprecated, use dict instead
(UP035)
[warning] 6-6: typing.List is deprecated, use list instead
(UP035)
[warning] 142-142: Consider moving this statement to an else block
(TRY300)
[error] 143-143: Local variable e is assigned to but never used
Remove assignment to unused variable e
(F841)
🔇 Additional comments (5)
packages/ts-moose-lib/src/scripts/workflow.ts (3)
139-153: ETL extract loop runs afteronCompletechildren — ordering concern.
hasMoreis checked after allonCompletechild tasks complete (lines 130–137). If the intent is extract → transform → load → next-batch-extract, this ordering is correct. But if the extract loop was previously independent of children, this is a behavioral change worth verifying.
98-98: LGTM — comment wording updated to match the"never"literal used at line 73.
134-137: No issue —.dataextraction is already present in child task execution.The code passes the full result object
{ task: string; data: any }to child tasks at line 135. Child tasks extract.dataat line 39 viainputData?.data || inputData, matching Python's behavior.Likely an incorrect or invalid review comment.
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py (2)
100-131: Direct execution + per-task continue-as-new check — clean improvement.Eliminates the polling monitor that was itself generating history events. The inline
is_continue_as_new_suggested()check between activities is the correct Temporal pattern.
116-145: Exception handling is correct.
ContinueAsNewErrorin the temporalio Python SDK directly subclassesBaseException, notException. This is intentional design — the exception will not be caught by theexcept Exceptionhandler at line 143, sofailed_stepwill not be corrupted.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
Show resolved
Hide resolved
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
Outdated
Show resolved
Hide resolved
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/ts-moose-lib/src/scripts/workflow.ts (1)
142-156:⚠️ Potential issue | 🟠 Major
executeTaskreturn type annotation is incorrect.
executeTaskat line 77 ofactivity.tsdeclaresPromise<any[]>, but actually returns whateverfullTask.config.run()produces. For extract tasks, this is{ items, hasMore }objects (peretlPipeline.tsline 109:Task<null, BatchResult<T>>), not arrays. Change return type toPromise<any>to match actual behavior.
🤖 Fix all issues with AI agents
In `@packages/ts-moose-lib/src/scripts/workflow.ts`:
- Around line 111-131: The current continueAsNew call restarts the workflow at
continue_from_task: task.name which causes ScriptWorkflow (see ScriptWorkflow
and its handleTask logic) to fetch and re-run the same task; either persist the
completed task result in the workflow state and update handleTask to detect and
skip re-execution when a task has a stored result, or change the continueAsNew
payload to advance to the next task (e.g., set continue_from_task to the first
child of the just-completed task instead of task.name) so the completed activity
is not re-executed; update the continueAsNew invocation and/or
ScriptWorkflow.handleTask to implement the chosen approach and ensure any tasks
that may run across a continueAsNew boundary are idempotent or have their
results persisted.
- Around line 137-140: The loop that invokes child tasks passes the raw result
to children (in the block iterating task.config.onComplete and calling
handleTask), causing inconsistency with Python which unwraps result.data when
present; change the value passed to handleTask to be result.data if result is an
object with a data property (e.g., BatchResult envelope) otherwise pass result,
so child tasks receive the same payload shape as the Python implementation;
adjust the child invocation in the for loop that calls handleTask(workflow,
childTask, ...) to compute const propagated = (result && typeof result ===
"object" && "data" in result) ? result.data : result and pass propagated.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.pypackages/ts-moose-lib/src/scripts/workflow.ts
🧰 Additional context used
📓 Path-based instructions (5)
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Run linting checks before submitting PRs for TypeScript/JavaScript code
**/*.{ts,tsx,js,jsx}: Group imports by external dependencies, internal modules, and types; use named exports from barrel files (index.ts)
Use camelCase for variables and functions, PascalCase for types/classes/components, UPPER_SNAKE_CASE for constants in TypeScript/JavaScript
Prefix unused variables with underscore (e.g.,_unusedParam) to bypass linting errors in TypeScript/JavaScript
Format TypeScript/JavaScript code with Prettier usingexperimentalTernaries: true; auto-formats on commit via Husky + lint-staged
Files:
packages/ts-moose-lib/src/scripts/workflow.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Prefer interfaces for objects, types for unions/intersections in TypeScript; explicit return types on public APIs
Files:
packages/ts-moose-lib/src/scripts/workflow.ts
**/ts-moose-lib/src/**/*.ts
⚙️ CodeRabbit configuration file
**/ts-moose-lib/src/**/*.ts: When reviewing changes to typescript moose lib:
- Check if any public apis were changed (class, method, type, config, etc).
- If yes, verify the documentation for THAT SPECIFIC feature is updated in apps/framework-docs-v2/content.
- If docs for that feature doesn't exist yet, it should be added. If the change removes public apis, the documentation for those should also be removed. Changing unrelated docs doesn't satisfy this requirement.
- In addition to reviewing for docs discrepancies, you should also review the code as per usual guidelines.
Files:
packages/ts-moose-lib/src/scripts/workflow.ts
**/*.py
📄 CodeRabbit inference engine (AGENTS.md)
**/*.py: Follow PEP 8 style guide in Python; use snake_case for functions/variables, PascalCase for classes, UPPER_SNAKE_CASE for constants
Format Python code with Black using line-length 88; auto-formats on commit via Husky + lint-staged
Use type hints for function signatures and public APIs in Python
Files:
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
**/framework-cli/src/**
⚙️ CodeRabbit configuration file
**/framework-cli/src/**: When reviewing changes to Moose CLI:
- Check if any user-facing changes were made (commands, flags, configs, apis, etc)
- If yes, verify the documentation for THAT SPECIFIC feature is updated in apps/framework-docs-v2/content
- If docs for that feature doesn't exist yet, it should be added. If the change removes public apis, the documentation for those should also be removed. Changing unrelated docs doesn't satisfy this requirement.
- In addition to reviewing for docs discrepancies, you should also review the code as per usual guidelines.
Files:
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
🧠 Learnings (4)
📓 Common learnings
Learnt from: DatGuyJonathan
Repo: 514-labs/moosestack PR: 3400
File: apps/framework-cli/src/framework/core/infrastructure_map.rs:1238-1298
Timestamp: 2026-01-26T00:56:27.011Z
Learning: Repo 514-labs/moosestack — Workflows: The CLI’s workflow diff is intended to detect only Temporal schedule–affecting changes. In apps/framework-cli/src/framework/core/infrastructure_map.rs, workflows_config_equal should compare schedule, retries, and timeout only; it must not include tasks. Task code/config changes are picked up automatically when the orchestration worker restarts and should not trigger a WorkflowChange.
📚 Learning: 2026-01-26T00:56:27.011Z
Learnt from: DatGuyJonathan
Repo: 514-labs/moosestack PR: 3400
File: apps/framework-cli/src/framework/core/infrastructure_map.rs:1238-1298
Timestamp: 2026-01-26T00:56:27.011Z
Learning: Repo 514-labs/moosestack — Workflows: The CLI’s workflow diff is intended to detect only Temporal schedule–affecting changes. In apps/framework-cli/src/framework/core/infrastructure_map.rs, workflows_config_equal should compare schedule, retries, and timeout only; it must not include tasks. Task code/config changes are picked up automatically when the orchestration worker restarts and should not trigger a WorkflowChange.
Applied to files:
packages/ts-moose-lib/src/scripts/workflow.tsapps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/workflows/*-sync.ts : Scheduled sync workflows should use Cron schedule expressions (e.g., '0 * * * *' for hourly, '*/5 * * * *' for every 5 minutes), fetch from external APIs using Bearer token authorization, and return a SyncResult object with synced count and errors
Applied to files:
packages/ts-moose-lib/src/scripts/workflow.ts
📚 Learning: 2026-01-26T01:14:58.758Z
Learnt from: DatGuyJonathan
Repo: 514-labs/moosestack PR: 3400
File: apps/framework-cli/src/framework/core/execute.rs:141-146
Timestamp: 2026-01-26T01:14:58.758Z
Learning: In apps/framework-cli/src/infrastructure/orchestration/workflows.rs, workflow scheduling failures should be non-fatal. The workflows::execute_changes function should return () and log errors rather than returning Result and propagating failures. Failing to schedule a workflow is not a reason to fail the deploy.
Applied to files:
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
🧬 Code graph analysis (1)
packages/ts-moose-lib/src/scripts/workflow.ts (1)
packages/ts-moose-lib/src/scripts/activity.ts (1)
executeTask(73-169)
🪛 Ruff (0.14.14)
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
[warning] 6-6: typing.Dict is deprecated, use dict instead
(UP035)
[warning] 6-6: typing.List is deprecated, use list instead
(UP035)
[warning] 142-142: Consider moving this statement to an else block
(TRY300)
🔇 Additional comments (4)
packages/ts-moose-lib/src/scripts/workflow.ts (1)
96-107: LGTM on timeout handling.Comment and logic cleanly distinguish
"never"(unlimited via largescheduleToCloseTimeout) from explicit and default timeouts. Consistent with Python side.apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py (3)
100-131: Clean simplification — same re-execution caveat as the TS side applies here.Removing the asyncio monitor/race in favor of a direct
await+ post-activity check is a solid improvement. The return-type narrowing toList[Any]is correct now thatContinueAsNewDatais gone.One note:
continue_as_newon line 122 raisesContinueAsNewError(never returns), soreturn awaitis technically dead as a return. Harmless, butawait workflow.continue_as_new(...)alone (withoutreturn) would be slightly more honest.The re-execution-on-continue concern (same task re-runs) applies identically here—see the corresponding TS comment.
147-150: Docstring is fine as-is.
194-262:runmethod handles both start and continue-as-new cleanly.The
isinstance(request, dict)guard (line 211) correctly handles Temporal deserialization. Task resolution logic forcontinue_from_taskis straightforward.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py (2)
220-222:⚠️ Potential issue | 🟡 MinorLogging raw
input_datamay leak sensitive information.Line 221 and 234 log the full workflow input. If workflows process PII or credentials, these end up in Temporal worker logs.
100-141:⚠️ Potential issue | 🟠 MajorPython workflows lack ETL extract pagination loop.
TypeScript
handleTask(lines 141–155) re-invokes extract tasks whenresult.hasMore === true. Python's_execute_activity_with_statehas no equivalent check—ETL extract pagination won't work for Python workflows.TypeScript implementation for reference
// Check if this is an ETL extract task that needs to loop // ETL extract tasks end with "_extract" and return BatchResult with hasMore if ( task.name.endsWith("_extract") && result && typeof result === "object" && "hasMore" in result && (result as any).hasMore === true ) { logger.info(`Extract task ${task.name} has more data, restarting chain...`); // Recursively call the extract task again to get the next batch const nextBatchResults = await handleTask(workflow, task, null); results.push(...nextBatchResults); }
🤖 Fix all issues with AI agents
In
`@apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py`:
- Around line 107-121: The code currently does "return await
workflow.continue_as_new(...)" which is misleading because
workflow.continue_as_new() raises ContinueAsNewError and never returns; change
it to a bare "await workflow.continue_as_new(...)" (remove the return) and add a
short comment explaining that continue_as_new raises ContinueAsNewError so
execution never resumes past this point; update the block referencing
workflow.continue_as_new, WorkflowRequest, task.name, wf.name, and input_data
accordingly.
In `@packages/ts-moose-lib/src/scripts/workflow.ts`:
- Around line 111-123: The call to continueAsNew inside the workflow branch
never returns (it throws a ContinueAsNewError) but the function signature claims
Promise<any[]>; make control flow explicit by adding an immediate return after
awaiting continueAsNew (or rethrow) so TypeScript and readers know execution
stops there—update the block that checks workflowInfo().continueAsNewSuggested
where continueAsNew({ workflow_name: workflow.name, execution_mode:
"continue_as_new", continue_from_task: task.name }, inputData) is awaited to
follow with a return (or throw) to mark the branch as terminal.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.pypackages/ts-moose-lib/src/scripts/workflow.ts
🧰 Additional context used
📓 Path-based instructions (5)
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Run linting checks before submitting PRs for TypeScript/JavaScript code
**/*.{ts,tsx,js,jsx}: Group imports by external dependencies, internal modules, and types; use named exports from barrel files (index.ts)
Use camelCase for variables and functions, PascalCase for types/classes/components, UPPER_SNAKE_CASE for constants in TypeScript/JavaScript
Prefix unused variables with underscore (e.g.,_unusedParam) to bypass linting errors in TypeScript/JavaScript
Format TypeScript/JavaScript code with Prettier usingexperimentalTernaries: true; auto-formats on commit via Husky + lint-staged
Files:
packages/ts-moose-lib/src/scripts/workflow.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Prefer interfaces for objects, types for unions/intersections in TypeScript; explicit return types on public APIs
Files:
packages/ts-moose-lib/src/scripts/workflow.ts
**/ts-moose-lib/src/**/*.ts
⚙️ CodeRabbit configuration file
**/ts-moose-lib/src/**/*.ts: When reviewing changes to typescript moose lib:
- Check if any public apis were changed (class, method, type, config, etc).
- If yes, verify the documentation for THAT SPECIFIC feature is updated in apps/framework-docs-v2/content.
- If docs for that feature doesn't exist yet, it should be added. If the change removes public apis, the documentation for those should also be removed. Changing unrelated docs doesn't satisfy this requirement.
- In addition to reviewing for docs discrepancies, you should also review the code as per usual guidelines.
Files:
packages/ts-moose-lib/src/scripts/workflow.ts
**/*.py
📄 CodeRabbit inference engine (AGENTS.md)
**/*.py: Follow PEP 8 style guide in Python; use snake_case for functions/variables, PascalCase for classes, UPPER_SNAKE_CASE for constants
Format Python code with Black using line-length 88; auto-formats on commit via Husky + lint-staged
Use type hints for function signatures and public APIs in Python
Files:
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
**/framework-cli/src/**
⚙️ CodeRabbit configuration file
**/framework-cli/src/**: When reviewing changes to Moose CLI:
- Check if any user-facing changes were made (commands, flags, configs, apis, etc)
- If yes, verify the documentation for THAT SPECIFIC feature is updated in apps/framework-docs-v2/content
- If docs for that feature doesn't exist yet, it should be added. If the change removes public apis, the documentation for those should also be removed. Changing unrelated docs doesn't satisfy this requirement.
- In addition to reviewing for docs discrepancies, you should also review the code as per usual guidelines.
Files:
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
🧠 Learnings (4)
📓 Common learnings
Learnt from: DatGuyJonathan
Repo: 514-labs/moosestack PR: 3400
File: apps/framework-cli/src/framework/core/infrastructure_map.rs:1238-1298
Timestamp: 2026-01-26T00:56:27.011Z
Learning: Repo 514-labs/moosestack — Workflows: The CLI’s workflow diff is intended to detect only Temporal schedule–affecting changes. In apps/framework-cli/src/framework/core/infrastructure_map.rs, workflows_config_equal should compare schedule, retries, and timeout only; it must not include tasks. Task code/config changes are picked up automatically when the orchestration worker restarts and should not trigger a WorkflowChange.
📚 Learning: 2026-01-26T00:56:27.011Z
Learnt from: DatGuyJonathan
Repo: 514-labs/moosestack PR: 3400
File: apps/framework-cli/src/framework/core/infrastructure_map.rs:1238-1298
Timestamp: 2026-01-26T00:56:27.011Z
Learning: Repo 514-labs/moosestack — Workflows: The CLI’s workflow diff is intended to detect only Temporal schedule–affecting changes. In apps/framework-cli/src/framework/core/infrastructure_map.rs, workflows_config_equal should compare schedule, retries, and timeout only; it must not include tasks. Task code/config changes are picked up automatically when the orchestration worker restarts and should not trigger a WorkflowChange.
Applied to files:
packages/ts-moose-lib/src/scripts/workflow.tsapps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/workflows/*-sync.ts : Scheduled sync workflows should use Cron schedule expressions (e.g., '0 * * * *' for hourly, '*/5 * * * *' for every 5 minutes), fetch from external APIs using Bearer token authorization, and return a SyncResult object with synced count and errors
Applied to files:
packages/ts-moose-lib/src/scripts/workflow.ts
📚 Learning: 2026-01-26T01:14:58.758Z
Learnt from: DatGuyJonathan
Repo: 514-labs/moosestack PR: 3400
File: apps/framework-cli/src/framework/core/execute.rs:141-146
Timestamp: 2026-01-26T01:14:58.758Z
Learning: In apps/framework-cli/src/infrastructure/orchestration/workflows.rs, workflow scheduling failures should be non-fatal. The workflows::execute_changes function should return () and log errors rather than returning Result and propagating failures. Failing to schedule a workflow is not a reason to fail the deploy.
Applied to files:
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
🪛 Ruff (0.14.14)
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
[warning] 6-6: typing.Dict is deprecated, use dict instead
(UP035)
[warning] 6-6: typing.List is deprecated, use list instead
(UP035)
🔇 Additional comments (3)
packages/ts-moose-lib/src/scripts/workflow.ts (2)
97-107: LGTM on timeout handling.Clear branching between normal timeout (
startToCloseTimeout) and unlimited (scheduleToCloseTimeout = 10 years). Comment accurately describes the rationale.
141-155: Extract task pagination state is correctly managed via batcher's internal iterator—passing null is correct.The extract task is typed as
Task<null, BatchResult<T>>, requiring null input by design. Pagination state lives in theETLPipeline.batcherinstance's internal iterator (created once, persists across calls), not ininputData. EachhandleTask()call invokesthis.batcher.getNextBatch(), which advances the iterator viaawait this.iterator.next(). Passing null is the intended behavior.Likely an incorrect or invalid review comment.
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py (1)
193-261:runmethod cleanly handles bothstartandcontinue_as_newmodes.Dict-to-dataclass coercion on line 210-211 is a good defensive pattern for Temporal serialization. Task resolution logic is clear.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
Show resolved
Hide resolved
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/ts-moose-lib/src/scripts/workflow.ts (1)
97-107: 🧹 Nitpick | 🔵 TrivialMagic value
"87600h"— extract to a named constant.Proposed fix
+// 10 years ≈ effectively unlimited; Temporal requires a finite timeout. +const UNLIMITED_TIMEOUT: Duration = "87600h"; + // ... } else { - activityOptions.scheduleToCloseTimeout = "87600h"; // 10 years + activityOptions.scheduleToCloseTimeout = UNLIMITED_TIMEOUT; }
🤖 Fix all issues with AI agents
In `@packages/ts-moose-lib/src/scripts/workflow.ts`:
- Around line 125-130: The executeTask function's return type is incorrect:
change its signature from Promise<any[]> to Promise<any> because executeTask
returns the single value from task.config.run() (with only the cancellation path
returning an empty array); update the type annotation for executeTask
accordingly and ensure any related callers (e.g., handleTask which wraps the
single result into results via results.push(result) and flattens child results)
still compile against the new Promise<any> return type.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
packages/ts-moose-lib/src/scripts/workflow.ts
🧰 Additional context used
📓 Path-based instructions (3)
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Run linting checks before submitting PRs for TypeScript/JavaScript code
**/*.{ts,tsx,js,jsx}: Group imports by external dependencies, internal modules, and types; use named exports from barrel files (index.ts)
Use camelCase for variables and functions, PascalCase for types/classes/components, UPPER_SNAKE_CASE for constants in TypeScript/JavaScript
Prefix unused variables with underscore (e.g.,_unusedParam) to bypass linting errors in TypeScript/JavaScript
Format TypeScript/JavaScript code with Prettier usingexperimentalTernaries: true; auto-formats on commit via Husky + lint-staged
Files:
packages/ts-moose-lib/src/scripts/workflow.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Prefer interfaces for objects, types for unions/intersections in TypeScript; explicit return types on public APIs
Files:
packages/ts-moose-lib/src/scripts/workflow.ts
**/ts-moose-lib/src/**/*.ts
⚙️ CodeRabbit configuration file
**/ts-moose-lib/src/**/*.ts: When reviewing changes to typescript moose lib:
- Check if any public apis were changed (class, method, type, config, etc).
- If yes, verify the documentation for THAT SPECIFIC feature is updated in apps/framework-docs-v2/content.
- If docs for that feature doesn't exist yet, it should be added. If the change removes public apis, the documentation for those should also be removed. Changing unrelated docs doesn't satisfy this requirement.
- In addition to reviewing for docs discrepancies, you should also review the code as per usual guidelines.
Files:
packages/ts-moose-lib/src/scripts/workflow.ts
🧠 Learnings (3)
📓 Common learnings
Learnt from: DatGuyJonathan
Repo: 514-labs/moosestack PR: 3400
File: apps/framework-cli/src/framework/core/infrastructure_map.rs:1238-1298
Timestamp: 2026-01-26T00:56:27.011Z
Learning: Repo 514-labs/moosestack — Workflows: The CLI’s workflow diff is intended to detect only Temporal schedule–affecting changes. In apps/framework-cli/src/framework/core/infrastructure_map.rs, workflows_config_equal should compare schedule, retries, and timeout only; it must not include tasks. Task code/config changes are picked up automatically when the orchestration worker restarts and should not trigger a WorkflowChange.
📚 Learning: 2026-01-26T00:56:27.011Z
Learnt from: DatGuyJonathan
Repo: 514-labs/moosestack PR: 3400
File: apps/framework-cli/src/framework/core/infrastructure_map.rs:1238-1298
Timestamp: 2026-01-26T00:56:27.011Z
Learning: Repo 514-labs/moosestack — Workflows: The CLI’s workflow diff is intended to detect only Temporal schedule–affecting changes. In apps/framework-cli/src/framework/core/infrastructure_map.rs, workflows_config_equal should compare schedule, retries, and timeout only; it must not include tasks. Task code/config changes are picked up automatically when the orchestration worker restarts and should not trigger a WorkflowChange.
Applied to files:
packages/ts-moose-lib/src/scripts/workflow.ts
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/workflows/*-sync.ts : Scheduled sync workflows should use Cron schedule expressions (e.g., '0 * * * *' for hourly, '*/5 * * * *' for every 5 minutes), fetch from external APIs using Bearer token authorization, and return a SyncResult object with synced count and errors
Applied to files:
packages/ts-moose-lib/src/scripts/workflow.ts
🧬 Code graph analysis (1)
packages/ts-moose-lib/src/scripts/workflow.ts (1)
packages/ts-moose-lib/src/scripts/activity.ts (1)
executeTask(73-169)
⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Test E2E TypeScript Tests Template (Node 20, npm)
🔇 Additional comments (1)
packages/ts-moose-lib/src/scripts/workflow.ts (1)
141-155: ETL loop ordering is correct: children process before next batch fetch.Lines 136–139 execute
onCompletechildren on the current batch result. Lines 143–155 checkhasMoreand recursively callhandleTaskto fetch the next batch. This produces: extract₁ → children₁ → extract₂ → children₂ → ...—the standard batch-process-then-fetch pattern. Python workflow implements the same ordering (apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py lines 132–136).
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py (1)
134-145: 🧹 Nitpick | 🔵 TrivialUse dict membership check instead of
hasattrforWorkflowStepResult.Line 142:
WorkflowStepResultis aTypedDictwith a guaranteed"data"key. Usinghasattr(result, "data")works at runtime but is non-idiomatic for dict-based types. Use the dict membership operator instead:result.get("data", result)orresult["data"] if result.get("data") is not None else result.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.pypackages/ts-moose-lib/src/scripts/workflow.ts
🧰 Additional context used
📓 Path-based instructions (5)
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Run linting checks before submitting PRs for TypeScript/JavaScript code
**/*.{ts,tsx,js,jsx}: Group imports by external dependencies, internal modules, and types; use named exports from barrel files (index.ts)
Use camelCase for variables and functions, PascalCase for types/classes/components, UPPER_SNAKE_CASE for constants in TypeScript/JavaScript
Prefix unused variables with underscore (e.g.,_unusedParam) to bypass linting errors in TypeScript/JavaScript
Format TypeScript/JavaScript code with Prettier usingexperimentalTernaries: true; auto-formats on commit via Husky + lint-staged
Files:
packages/ts-moose-lib/src/scripts/workflow.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (AGENTS.md)
Prefer interfaces for objects, types for unions/intersections in TypeScript; explicit return types on public APIs
Files:
packages/ts-moose-lib/src/scripts/workflow.ts
**/ts-moose-lib/src/**/*.ts
⚙️ CodeRabbit configuration file
**/ts-moose-lib/src/**/*.ts: When reviewing changes to typescript moose lib:
- Check if any public apis were changed (class, method, type, config, etc).
- If yes, verify the documentation for THAT SPECIFIC feature is updated in apps/framework-docs-v2/content.
- If docs for that feature doesn't exist yet, it should be added. If the change removes public apis, the documentation for those should also be removed. Changing unrelated docs doesn't satisfy this requirement.
- In addition to reviewing for docs discrepancies, you should also review the code as per usual guidelines.
Files:
packages/ts-moose-lib/src/scripts/workflow.ts
**/*.py
📄 CodeRabbit inference engine (AGENTS.md)
**/*.py: Follow PEP 8 style guide in Python; use snake_case for functions/variables, PascalCase for classes, UPPER_SNAKE_CASE for constants
Format Python code with Black using line-length 88; auto-formats on commit via Husky + lint-staged
Use type hints for function signatures and public APIs in Python
Files:
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
**/framework-cli/src/**
⚙️ CodeRabbit configuration file
**/framework-cli/src/**: When reviewing changes to Moose CLI:
- Check if any user-facing changes were made (commands, flags, configs, apis, etc)
- If yes, verify the documentation for THAT SPECIFIC feature is updated in apps/framework-docs-v2/content
- If docs for that feature doesn't exist yet, it should be added. If the change removes public apis, the documentation for those should also be removed. Changing unrelated docs doesn't satisfy this requirement.
- In addition to reviewing for docs discrepancies, you should also review the code as per usual guidelines.
Files:
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
🧠 Learnings (5)
📓 Common learnings
Learnt from: DatGuyJonathan
Repo: 514-labs/moosestack PR: 3400
File: apps/framework-cli/src/framework/core/infrastructure_map.rs:1238-1298
Timestamp: 2026-01-26T00:56:27.011Z
Learning: Repo 514-labs/moosestack — Workflows: The CLI’s workflow diff is intended to detect only Temporal schedule–affecting changes. In apps/framework-cli/src/framework/core/infrastructure_map.rs, workflows_config_equal should compare schedule, retries, and timeout only; it must not include tasks. Task code/config changes are picked up automatically when the orchestration worker restarts and should not trigger a WorkflowChange.
📚 Learning: 2026-01-26T00:56:27.011Z
Learnt from: DatGuyJonathan
Repo: 514-labs/moosestack PR: 3400
File: apps/framework-cli/src/framework/core/infrastructure_map.rs:1238-1298
Timestamp: 2026-01-26T00:56:27.011Z
Learning: Repo 514-labs/moosestack — Workflows: The CLI’s workflow diff is intended to detect only Temporal schedule–affecting changes. In apps/framework-cli/src/framework/core/infrastructure_map.rs, workflows_config_equal should compare schedule, retries, and timeout only; it must not include tasks. Task code/config changes are picked up automatically when the orchestration worker restarts and should not trigger a WorkflowChange.
Applied to files:
packages/ts-moose-lib/src/scripts/workflow.tsapps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/workflows/*-sync.ts : Scheduled sync workflows should use Cron schedule expressions (e.g., '0 * * * *' for hourly, '*/5 * * * *' for every 5 minutes), fetch from external APIs using Bearer token authorization, and return a SyncResult object with synced count and errors
Applied to files:
packages/ts-moose-lib/src/scripts/workflow.ts
📚 Learning: 2026-01-15T19:41:53.563Z
Learnt from: CR
Repo: 514-labs/moosestack PR: 0
File: examples/cdp-analytics/CLAUDE.md:0-0
Timestamp: 2026-01-15T19:41:53.563Z
Learning: Applies to examples/cdp-analytics/app/services/analyticsService.ts : Service functions in analyticsService.ts should execute queries using executeQuery helper, transform raw results, and return typed data structures defined in types/analytics.ts
Applied to files:
packages/ts-moose-lib/src/scripts/workflow.ts
📚 Learning: 2026-01-26T01:14:58.758Z
Learnt from: DatGuyJonathan
Repo: 514-labs/moosestack PR: 3400
File: apps/framework-cli/src/framework/core/execute.rs:141-146
Timestamp: 2026-01-26T01:14:58.758Z
Learning: In apps/framework-cli/src/infrastructure/orchestration/workflows.rs, workflow scheduling failures should be non-fatal. The workflows::execute_changes function should return () and log errors rather than returning Result and propagating failures. Failing to schedule a workflow is not a reason to fail the deploy.
Applied to files:
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
🧬 Code graph analysis (1)
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py (2)
packages/py-moose-lib/moose_lib/dmv2/workflow.py (2)
Workflow(132-189)Task(56-112)apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/types.py (1)
WorkflowStepResult(5-7)
🪛 Ruff (0.14.14)
apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py
[warning] 6-6: typing.Dict is deprecated, use dict instead
(UP035)
[warning] 6-6: typing.List is deprecated, use list instead
(UP035)
[warning] 147-147: Consider moving this statement to an else block
(TRY300)
⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Test E2E TypeScript Tests Template (Node 20, npm)
🔇 Additional comments (7)
packages/ts-moose-lib/src/scripts/workflow.ts (5)
20-22: Clean context type.Simple and effective way to thread the original input through
continueAsNewboundaries.
118-131: Good fix — pre-check eliminates the duplicate-execution problem.Moving the
continueAsNewSuggestedcheck before the activity runs meanscontinue_from_tasknow correctly points to an unexecuted task. Solid improvement.
133-138: Removing the polling monitor is the right call.The comment correctly explains that a running activity doesn't generate workflow history events. This eliminates the self-inflicted history growth.
56-58: Context threading looks correct.Original
inputDatais preserved throughcontinueAsNewboundaries and re-processed consistently on restart via line 43.
149-163:BatchResulthashasMoreat the top level; code access pattern is correct.The interface definition in
packages/ts-moose-lib/src/dmv2/sdk/etlPipeline.tsshowshasMoreas a top-level property ofBatchResult, matching the access pattern in lines 155–156.apps/framework-cli/src/framework/python/wrappers/scripts/python_worker_wrapper/workflow.py (2)
100-146: Preflight continue-as-new check and simplified execution look correct.The recursive threading of
original_workflow_inputthrough child tasks is sound — continue-as-new will always replay from the raw input. Activity execution without the polling monitor avoids the history-growth problem this PR targets.
264-267: Correct separation of processed vs. raw input.
current_data(processed) goes to the activity;input_data(raw) is preserved for continue-as-new replay. This avoids double-decoding on restart.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
1 participant
It was overly aggressive checking if it's reaching event limits, but every check was creating events. Really just need to check the limit before the task.
Note
Medium Risk
Changes core workflow execution/continue-as-new behavior; mistakes could cause incorrect resume points or altered task input propagation, though the change is localized and conceptually simple.
Overview
Fixes overly aggressive continue-as-new polling in both the Python worker wrapper and the TypeScript workflow implementation.
The workflow now checks
continue-as-newonce before starting each task (socontinue_from_taskpoints to an unexecuted task and avoids duplicate runs) and removes the background/polling monitor logic that was generating extra workflow history. The original raw workflow input is also threaded through tocontinue_as_newto avoid double-processing/serialization on restart, and TS child-task chaining/ETLhasMorehandling is updated to pass the full prior result object through the chain.Written by Cursor Bugbot for commit 20982b1. This will update automatically on new commits. Configure here.