Repository navigation
fix(workflows): load custom steps before update - #4768
Conversation
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Process-global custom steps can leak across projects and incorrectly validate an update.
Review effort: Balanced
Findings: 1
Open (1)
What changed in this PR
Loads custom workflow steps before validating workflow updates.
Changes:
- Registers project custom steps during
workflow update. - Adds success and transactional rejection regressions.
| File | Description |
|---|---|
src/specify_cli/workflows/command_update.py |
Loads custom steps before update validation. |
tests/specify_cli/workflows/test_command_update.py |
Tests custom and unknown step updates. |
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| from .catalog import WorkflowCatalog, WorkflowCatalogError | ||
|
|
||
| project_root = cli._require_specify_project() | ||
| load_custom_steps(project_root) |
There was a problem hiding this comment.
Addressed on the current head. workflow update calls load_custom_steps(project_root) before validating the downloaded workflow. load_custom_steps() clears non-built-in registry entries and tracked synthetic imports before loading the active project's steps. This prevents a type installed only in project A from validating project B, while allowing B's implementation to replace A's when both use the same key.
Coverage proves these at two boundaries: test_update_refreshes_custom_steps_between_projects directly exercises consecutive A-to-B CLI updates and verifies that B rejects A's type without changing B's installed workflow file or persistent WorkflowRegistry metadata. Separately, test_custom_steps_refresh_for_active_project loads distinct A and B implementations under the same key and verifies that B's implementation is active after the switch. The focused workflow modules passed: 24 passed. No additional code change is needed for this finding.
|
Please address Copilot feedback |
There was a problem hiding this comment.
🟢 Approval recommended
The focused fix is consistent with existing workflow commands and has comprehensive regression coverage.
1 open finding
🧠 Review effort: Balanced
Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.
|
Please address Copilot feedback |
|
@mnriem Thank you for the follow-up. I've addressed the Copilot feedback by refreshing project-local custom steps before I noticed that #4470 also includes broader project-scoped registry isolation. When convenient, could you advise whether you'd prefer to keep #4768 as a narrow update-path fix or consolidate it with #4470? I'm happy to follow your guidance. |
|
Please address Copilot feedback. If not applicable please explain why |
|
@mnriem Thanks for the follow-up. I’ve replied directly to the Copilot review thread with the current behavior and regression-test evidence: #4768 (comment). |
|
Thank you! |

Description
Load project-installed custom workflow steps before
workflow updatevalidates downloaded candidates. This aligns update with add, run, and resume while using the active project's custom-step registry.The update path now refreshes project-local custom steps between projects, so a type from one project is not accepted when updating another. Invalid updates continue to leave the installed workflow and registry unchanged.
Testing
tests/specify_cli/workflows/test_command_update.pyandtest_custom_steps.py: 24 passedtests/specify_cli/workflows: 588 passed, 1 skippedtests/test_workflows.py: 779 passedgit diff --check origin/main