fix(mcp-openapi): plugin creation fails when creating OpenAPI MCP plugin in plugin management
Co-authored-by: michaelhuawei<michael.atamuk@huawei.com>
# message auto-generated for no-merge-commit merge:
!1036 merge fix/mcp-openapi-plugin-creation-838 into develop
fix(mcp-openapi): plugin creation fails when creating OpenAPI MCP plugin in plugin management
Created-by: michaelhuawei
Commit-by: Michael;michaelhuawei
Merged-by: ZYQ5333
Description: **What type of PR is this?**
/kind bug
---
**What does this PR do / why do we need it**:
This PR fixes **Bug #838**, where creating an **OpenAPI MCP Plugin** in the Plugin Management UI resulted in a plugin creation error.
The root cause was incorrect URL/file‑path validation across backend and frontend layers.
The fixes include:
### **Backend**
- validate_plugin_url now strips whitespace and handles empty values safely.
- _validate_openapi_paths rewritten to correctly support:
- Multiple comma‑separated entries
- Both URLs and local file paths
- SSRF‑safe URL validation via validate_plugin_url
- File‑path existence checks without over‑restrictive “safe root” rules
- plugin_create now validates URLs **only when the input is actually a URL**, not a file path.
- PluginCreate schema (model_post_init) updated:
- OPENAPI transport accepts **URL or file path**
- SSE / Streamable HTTP transports require **URL only**
- Clearer error messages for invalid combinations
### **Frontend**
- isValidUrl updated to correctly bypass URL parsing for file paths.
- isUrlFieldValid updated so OpenAPI transport accepts both URLs and file paths.
- Prevents false validation errors in the MCP Plugin creation dialog.
These changes ensure that OpenAPI MCP plugins can be created successfully using either remote OpenAPI URLs or local OpenAPI spec files.
---
**Which issue(s) this PR fixes**:
Fixes #838
---
**Code review checklist**:
+ - [ ] whether to verify the function's return value
+ - [ ] Whether to comply with **SOLID principle / Demeter's law**
+ - [ ] Whether there is UT test case && the test case is valid (if no test case, explain why)
+ - [ ] Whether the API change is involved
+ - [ ] Whether official document modification is involved
See merge request: openJiuwen/agent-studio!1036
fix : Add idempotent support for unique constraint operations in migrations
Co-authored-by: cs123abc<chensheng63@huawei.com>
# message auto-generated for no-merge-commit merge:
!760 merge develop-20260228-v3 into develop
fix : Add idempotent support for unique constraint operations in migrations
Created-by: chensheng12345
Commit-by: cs123abc
Merged-by: ZYQ5333
Description: <!-- Thanks for sending a pull request! Here are some tips for you:
1) If this is your first time, please read our contributor guidelines: https://gitcode.com/openJiuwen/openJiuwen/blob/master/CONTRIBUTING.md
2) If you want to contribute your code but don't know who will review and merge, please add label openJiuwen-assistant to the pull request, we will find and do it as soon as possible.
-->
**What type of PR is this?**
<!--
Choose one label from bug, task, feature and refactor, and replace <label> below the comment block.
If this pr is not only bugfix/task/feature and also a refactor, you can append /kind refactor label after /kind bug, /kind task and /kind feature.
-->
/kind fix
**What does this PR do / why do we need it**:
* Need to describe clearly
**Which issue(s) this PR fixes**:
<!--
*Automatically closes linked issue when PR is merged.
Usage: Fixes #<issue number>, or Fixes (paste link of issue).
-->
Fixes #
**What scenarios were tested, and what were the verification results（Function, performance, reliability, etc.）**：
* Need to describe clearly
**Self-checklist**:（**Please check carefully,and mark an x in the [] brackets. We will review your completion status.**）
+ - [x] **Design**: Has the solution corresponding to the PR been reviewed by the Maintainer, and have all review comments been replied to and revised
+ - [x] **Test**: Has the code in the PR been fully covered by UT/ST test cases, and have the newly added test cases been uploaded to the repository along with this PR or already uploaded.
+ - [x] **Verification**: Does the PR description contains a detailed description of the verification results regarding the achievement of the expected goals for the Feature, Refactor, and Bugfix to this PR.
+ - [x] **Interface**: Does it involve changes to external interfaces? The corresponding changes have been approved by the interface review organization, and the annotation information for the API has been correctly refreshed.
+ - [x] **Document**: Does it involve modifications to the official website documentation? If so, please submit the materials to the Doc repository in a timely manner.
<!-- **Special notes for your reviewers**: -->
<!-- + - [ ] Whether it causes forward compatibility failure -->
<!-- + - [ ] Whether the dependent third-party library change is involved -->
See merge request: openJiuwen/agent-studio!760
Fix n8n workflows import with Http Node
Co-authored-by: nizzan<nizzan.kimhi@huawei.com>
Co-authored-by: @aharonamir1<amir.aharon@huawei.com>
# message auto-generated for no-merge-commit merge:
!1045 merge fix-import-http-react into develop
Fix n8n workflows import with Http Node
Created-by: aharonamir1
Commit-by: @aharonamir1;nizzan
Merged-by: ZYQ5333
Description: <!-- Thanks for sending a pull request! Here are some tips for you:
1) If this is your first time, please read our contributor guidelines: https://gitcode.com/openJiuwen/community/blob/master/CONTRIBUTING.md
2) If you want to contribute your code but don't know who will review and merge, please add label openjiuwen-assistant to the pull request, we will find and do it as soon as possible.
-->
**What type of PR is this?**
<!--
选择下面一种标签替换下方 /kind <label>，可选标签类型有：
- /kind bug
- /kind task
- /kind feature
- /kind refactor
- /kind clean_code
如PR描述不符合规范，修改PR描述后需要/check-pr重新检查PR规范。
-->
/kind bug
Relates to [#825](https://gitcode.com/openJiuwen/agent-studio/issues/825)
Fixing Import for Http Node with chat triggers node
**Self-checklist**:（**请自检，在[ ]内打上x，我们将检视你的完成情况，否则会导致pr无法合入**）
+ - [ ] **设计**：PR对应的方案是否已经经过Maintainer评审，方案检视意见是否均已答复并完成方案修改
+ - [x] **测试**：PR中的代码是否已有UT/ST测试用例进行充分的覆盖，新增测试用例是否随本PR一并上库或已经上库
+ - [x] **验证**：PR描述信息中是否已包含对该PR对应的Feature、Refactor、Bugfix的预期目标达成情况的详细验证结果描述
+ - [ ] **接口**：是否涉及对外接口变更，相应变更已得到接口评审组织的通过，API对应的注释信息已经刷新正确
+ - [ ] **文档**：是否涉及官网文档修改，如果涉及请及时提交资料到Doc仓
<!-- **Special notes for your reviewers**: -->
<!-- + - [ ] 是否导致无法前向兼容 -->
<!-- + - [ ] 是否涉及依赖的三方库变更 -->
See merge request: openJiuwen/agent-studio!1045
fix(mcp-stdio): correct discovery and invocation logic for stdio MCP plugins
Co-authored-by: michaelhuawei<michael.atamuk@huawei.com>
# message auto-generated for no-merge-commit merge:
!1074 merge fix/mcp-stdio-plugin-params into develop
fix(mcp-stdio): correct discovery and invocation logic for stdio MCP plugins
Created-by: michaelhuawei
Commit-by: michaelhuawei
Merged-by: ZYQ5333
Description: **What type of PR is this?**
/kind bug
**What does this PR do / why do we need it**:
This PR fixes **stdio MCP plugin discovery and invocation**, which were still broken even after the fix for #835.
The root cause was that the backend constructed incorrect params for stdio plugins, and the invocation path attempted to execute the .py script directly instead of running it via Python.
---
## ✔ 1. Fix: Stdio discovery was broken
### **Root cause**
_build_safe_stdio_params incorrectly used: args = [config.url]
But for stdio plugins:
- config.url is always ""
- The actual script path is stored in:
- config.params["command"]
- config.params["args"]
- config.params["env"]
### **Fix**
Discovery now uses:
script_path = params["command"] or config.url or ""
args = params["args"]
env = params["env"]
This matches what StdioClient expects.
---
## ✔ 2. Fix: Stdio invocation was broken
### **Root cause**
plugin_tools.py passed: command = params["command"] # e.g. "/path/to/server.py"
This caused:
because the .py file was executed directly instead of via Python.
### **Fix**
Invocation now treats:
- params["command"] as the **script path**
- sys.executable as the **actual executable**
Updated logic:
script_path = params["command"]
extra_args = params["args"]
mcp_params["command"] = sys.executable
mcp_params["args"] = [script_path] + extra_args
Now the process launches as: python /path/to/server.py "arg1" "arg2"
---
## 🎉 Result
- Stdio plugin **discovery works**
- Stdio plugin **invocation works**
- Both discovery and execution now correctly use:
- Python interpreter
- Script path from DB
- Args and env from DB
This completes the stdio MCP plugin support.
---
**Which issue(s) this PR fixes**:
Follow‑up to [#835](https://gitcode.com/openJiuwen/agent-studio/issues/835)
---
**Code review checklist**:
+ - [ ] whether to verify the function's return value
+ - [ ] Whether to comply with **SOLID principle / Demeter's law**
+ - [ ] Whether there is UT test case && the test case is valid (if no test case, explain why)
+ - [ ] Whether the API change is involved
+ - [ ] Whether official document modification is involved
See merge request: openJiuwen/agent-studio!1074
fix(triggers): correct weekly cron day-of-week mapping for APScheduler
Co-authored-by: michaelhuawei<michael.atamuk@huawei.com>
# message auto-generated for no-merge-commit merge:
!1077 merge fix/trigger-edit-version-dropdown into develop
fix(triggers): correct weekly cron day-of-week mapping for APScheduler
Created-by: michaelhuawei
Commit-by: michaelhuawei
Merged-by: ZYQ5333
Description: **What type of PR is this?**
/kind bug
**What does this PR do / why do we need it**:
Testers reported that **weekly triggers run one day later than intended**.
Example:
- User selects **Friday 09:00**
- APScheduler logs: next_run_utc = 2026‑05‑30 09:00:00+00:00
which is **Saturday**, not Friday.
Daily and monthly triggers were unaffected.
---
## ✔ Root Cause
APScheduler 3.x uses a **different day-of-week numbering** than POSIX cron:
| Meaning | POSIX cron | APScheduler |
|--------|------------|-------------|
| Monday | 1 | 0 |
| Friday | 5 | 4 |
| Saturday | 6 | 5 |
The frontend generated POSIX numeric DOW values (5 for Friday).
APScheduler interpreted that as its own 5 → **Saturday**.
Confirmed with APScheduler 3.11.2:
from_crontab("0 9 * * 5") → Saturday (wrong)
from_crontab("0 9 * * fri") → Friday (correct)
APScheduler correctly handles **day abbreviations**, not POSIX numbers.
---
## ✔ Fix Implemented
### **1. Frontend: CronConfigForm.tsx**
- Weekly cron builder now emits **day abbreviations** (mon, tue, fri) instead of numbers.
- Parser updated to accept both numeric and abbreviation formats for backward compatibility.
### **2. Backend: jobs.py**
Added _normalize_posix_cron():
- Converts numeric DOW tokens (5) into day abbreviations (fri)
- Handles:
- single values (5)
- lists (1,3,5)
- ranges (1-5)
- steps (1-5/2)
- Applied before calling CronTrigger.from_crontab()
This ensures correctness even for manually typed cron expressions.
---
## 🎉 Result
Weekly triggers now schedule on the correct day:
- Friday → Friday
- Monday → Monday
- All weekly schedules now match user intent
- Daily and monthly triggers remain unchanged
---
**Which issue(s) this PR fixes**:
Reported by testers (no formal issue number)
---
**Code review checklist**:
+ - [ ] whether to verify the function's return value
+ - [ ] Whether to comply with **SOLID principle / Demeter's law**
+ - [ ] Whether there is UT test case && the test case is valid (if no test case, explain why)
+ - [ ] Whether the API change is involved
+ - [ ] Whether official document modification is involved
See merge request: openJiuwen/agent-studio!1077
fix: runtime agent支持工作流&插件运行
Co-authored-by: ldstyle8<liudongdong46@huawei.com>
# message auto-generated for no-merge-commit merge:
!953 merge dev into develop
fix: runtime agent支持工作流&插件运行
Created-by: ldstyle8
Commit-by: ldstyle8
Merged-by: ZYQ5333
Description: <!-- Thanks for sending a pull request! Here are some tips for you:
1) If this is your first time, please read our contributor guidelines: https://gitcode.com/openJiuwen/community/blob/master/CONTRIBUTING.md
2) If you want to contribute your code but don't know who will review and merge, please add label openjiuwen-assistant to the pull request, we will find and do it as soon as possible.
-->
**What type of PR is this?**
<!--
选择下面一种标签替换下方 /kind <label>，可选标签类型有：
- /kind bug
- /kind task
- /kind feature
- /kind refactor
- /kind clean_code
如PR描述不符合规范，修改PR描述后需要/check-pr重新检查PR规范。
-->
/kind fix
**Self-checklist**:（**请自检，在[ ]内打上x，我们将检视你的完成情况，否则会导致pr无法合入**）
+ - [x] **设计**：PR对应的方案是否已经经过Maintainer评审，方案检视意见是否均已答复并完成方案修改
+ - [x] **测试**：PR中的代码是否已有UT/ST测试用例进行充分的覆盖，新增测试用例是否随本PR一并上库或已经上库
+ - [x] **验证**：PR描述信息中是否已包含对该PR对应的Feature、Refactor、Bugfix的预期目标达成情况的详细验证结果描述
+ - [ ] **接口**：是否涉及对外接口变更，相应变更已得到接口评审组织的通过，API对应的注释信息已经刷新正确
+ - [ ] **文档**：是否涉及官网文档修改，如果涉及请及时提交资料到Doc仓
<!-- **Special notes for your reviewers**: -->
<!-- + - [ ] 是否导致无法前向兼容 -->
<!-- + - [ ] 是否涉及依赖的三方库变更 -->
See merge request: openJiuwen/agent-studio!953