fix: switch copaw-worker runtime entrypoint to qwenpaw#950
Conversation
📊 CI Metrics ReportSummary
By Role
Per-Test Breakdown
Trends✅ 1 test(s) improved (fewer LLM calls) Generated by HiClaw CI on 2026-07-04 05:09:12 UTC |
|
这个迁移方向是合理的，但当前实现还有几个合并前需要补齐的运行时接线问题。
建议二选一：
Dockerfile 已经把 Matrix channel 覆盖到
PR 描述里说 TeamHarness adapter 会调用
现在用的是
这个 PR 修改了 另外，CI 评论里有旧提交上的集成测试失败，以及 最后，@maplefeng-a 也在做相关的工作，可以看看是否存在逻辑上不一致的地方。 This migration direction is reasonable, but the current implementation still has several runtime wiring issues that need to be patched before merging.
It is recommended to choose one of the two:
The Dockerfile has overwritten the Matrix channel to
The PR description says that the TeamHarness adapter will call
Currently,
This PR modifies the content that will enter the image under In addition, there are integration test failures on old commits in the CI comments, and the token/call of Finally, @mapplefeng-a is also doing related work to see if there are any logical inconsistencies. |
1. Working dir: export QWENPAW_WORKING_DIR alongside COPAW_WORKING_DIR so qwenpaw.constant resolves the runtime dir without relying on legacy COPAW_ fallback alone. 2. Dockerfile: add qwenpaw CLI symlink to PATH for TeamHarness adapter compatibility. 3. bridge.py: change agents.profiles injection from shallow setdefault() to nested merge. Previously, if config.json already had an 'agents' key, profiles/active_agent/workspace_dir were not injected. Now each sub-key is setdefault'd individually. 4. chanhelog: add PR agentscope-ai#950 entries for copaw/ image-affecting changes. Note on Matrix config overlay: the maintainer asked about potential inconsistency between the config.py overlay (copied to copaw/config/) and qwenpaw.config.config. Analysis confirms no inconsistency: - Matrix channel.py (overlaid to qwenpaw/app/channels/matrix/) does not import from config.py at all — it only depends on BaseChannel and agentscope_runtime, both available via the dual fallback. - The HiClaw config overlay (copaw/src/matrix/config.py) adds HiClaw-specific channel types to copaw.config.config and is only needed by copaw.app. qwenpaw.app loads qwenpaw.config.config (its own module), and the channel layer is config-agnostic.
maplefeng-a
left a comment
maplefeng-a
left a comment
There was a problem hiding this comment.
Thanks for the follow-up. I checked the latest head, and this PR still has conflicts with main (copaw/Dockerfile, copaw/scripts/copaw-worker-entrypoint.sh, copaw/src/copaw_worker/bridge.py, and copaw/src/copaw_worker/worker.py).
Please rebase or merge main and resolve those conflicts first. Once the branch is clean again, I can continue the code review on the updated diff.
我看了最新 head，目前这个 PR 仍然和 main 有冲突，涉及 copaw/Dockerfile、copaw/scripts/copaw-worker-entrypoint.sh、copaw/src/copaw_worker/bridge.py 和 copaw/src/copaw_worker/worker.py。
请先 rebase 或 merge main 并解决冲突；分支干净后我再继续基于最新 diff 做代码 review。
- worker.py: change import and uvicorn target from copaw.app to qwenpaw.app - bridge.py: inject agents.profiles section into config.json (required by qwenpaw) - matrix/channel.py: update channel base import path to qwenpaw - Dockerfile: overlay matrix channel to qwenpaw path; add pip install qwenpaw - health.py: update docstring to reflect qwenpaw entrypoint - test_worker_health.py: update mock paths for qwenpaw namespace This enables spawn_subagent and other qwenpaw multi-agent features for all Workers while keeping the 'copaw' runtime name in HiClaw CRDs. The qwenpaw package is installed alongside copaw in the same venv; only the Worker entrypoint switches to qwenpaw directly. This also unblocks TeamHarness Phase 4 (QwenPaw Worker integration) — the adapter code already targets qwenpaw imports and CLI, but workers currently start copaw.app.
The import from qwenpaw.app.channels.base is correct for Workers (which have qwenpaw installed), but the Manager copaw image (manager/Dockerfile.copaw) also overlays this channel.py and only has copaw installed. Without qwenpaw, the ImportError handler fell back to BaseChannel=object, making MatrixChannel invisible to the copaw framework's channel loader (issubclass check fails). Add a nested try/except that imports from copaw.app.channels.base as a second fallback before degrading to object. This keeps the Manager copaw image working without requiring qwenpaw to be installed there.
The Manager copaw image overlays copaw/src/matrix/channel.py which now imports from qwenpaw.app.channels.base. While channel.py has a copaw fallback, installing qwenpaw in the Manager image ensures the primary import path works and aligns the Manager's Python environment with the Worker image.
The old comment said 'only executed inside a qwenpaw environment' which is no longer accurate since manager/Dockerfile.copaw also overlays this file but may only have copaw installed.
The dual fallback in channel.py correctly uses qwenpaw's BaseChannel when qwenpaw is available (Worker) and falls back to copaw's BaseChannel when it's not (Manager). Installing qwenpaw in the Manager causes the fallback to pick qwenpaw's BaseChannel, which then fails the copaw framework's issubclass check during channel registration — since copaw.app.channels.base.BaseChannel and qwenpaw.app.channels.base.BaseChannel are different classes in different packages. The Manager only needs copaw; the channel.py dual fallback handles the rest.
… replies When the copaw manager (without qwenpaw) uses the fallback path, ContentType/MessageType/RunStatus were set to None even though agentscope_runtime is available. This caused all Manager replies to be empty (null), failing 5 CI tests. Move the agentscope_runtime import into the copaw fallback try block, only falling through to None when the import truly fails.
1. Working dir: export QWENPAW_WORKING_DIR alongside COPAW_WORKING_DIR so qwenpaw.constant resolves the runtime dir without relying on legacy COPAW_ fallback alone. 2. Dockerfile: add qwenpaw CLI symlink to PATH for TeamHarness adapter compatibility. 3. bridge.py: change agents.profiles injection from shallow setdefault() to nested merge. Previously, if config.json already had an 'agents' key, profiles/active_agent/workspace_dir were not injected. Now each sub-key is setdefault'd individually. 4. chanhelog: add PR agentscope-ai#950 entries for copaw/ image-affecting changes. Note on Matrix config overlay: the maintainer asked about potential inconsistency between the config.py overlay (copied to copaw/config/) and qwenpaw.config.config. Analysis confirms no inconsistency: - Matrix channel.py (overlaid to qwenpaw/app/channels/matrix/) does not import from config.py at all — it only depends on BaseChannel and agentscope_runtime, both available via the dual fallback. - The HiClaw config overlay (copaw/src/matrix/config.py) adds HiClaw-specific channel types to copaw.config.config and is only needed by copaw.app. qwenpaw.app loads qwenpaw.config.config (its own module), and the channel layer is config-agnostic.
LUOSENGWA
force-pushed
the
fix/copaw-to-qwenpaw-migration
branch
from
3014704 to
9911d12
Compare
…oid shadowing original 3-arg version
qwenpaw depends on agentscope==1.0.20 which conflicts with copaw's agentscope version when resolved in the same pip install. Installing them in separate pip commands (copaw-worker first, then qwenpaw) mirrors the production deployment approach that works on Node1.
The copaw worker adapter's build_worker_readiness() waited for a marker
file (/tmp/hiclaw-copaw-{name}-matrix-ready) that was written by copaw's
own Matrix channel after initial sync. After switching to qwenpaw, the
Matrix channel is qwenpaw/app/channels/matrix/channel.py which has no
knowledge of HICLAW_MATRIX_CHANNEL_READY_FILE — the marker was never
created, causing /worker/readyz to permanently return not_ready.
Fix: use qwenpaw's standard GET /config/channels/matrix/health API
instead of the legacy inter-process marker file side-channel. This
API is available for every channel in qwenpaw and is the canonical
way to check channel readiness.
Root cause of CI test failures: test-02, test-15, test-21.
3 participants
Summary
Switch copaw-worker from copaw.app to qwenpaw.app as the runtime
entrypoint. qwenpaw is already present in the image as a dependency
of copaw; this change makes Workers use it directly, enabling
spawn_subagent and the full qwenpaw multi-agent feature set.
Changes (6 files, +31/-12)
Validation
Relation to TeamHarness
This PR is a prerequisite for TeamHarness Phase 4 (QwenPaw Worker
integration). The adapter code in
plugins/teamharness/adapters/qwenpaw/already imports from
qwenpaw.*modules and callsqwenpaw plugin install,but those can't work until Workers actually start
qwenpaw.app.The
agents.profilesinjection inbridge.pyfeeds directly intoTeamHarness's
_iter_qwenpaw_agents().What this does NOT change
HICLAW_COPAW_WORKER_IMAGEdefault value