test(qa): cover Crabline Zalo transport#99303
Conversation
Dependency GuardThis PR changes dependency-related files. Maintainers should confirm these changes are intentional. Changed files:
Maintainer follow-up:
|
Dependency graph changes are blockedOpenClaw does not accept dependency graph changes through PRs unless a repository admin or security explicitly authorizes the current head SHA. Dependency updates are generated internally by maintainers so external PRs cannot change the resolved graph. Detected dependency graph changes:
Auto-scrub was not attempted because this PR changes package manifest dependency graph fields:
Dependency graph changes must be reviewed by security or handled by maintainers internally. Please remove lockfile changes manually if they are not needed. To remove lockfile changes, restore them from the target branch: git fetch origin
git checkout 'origin/main' -- 'pnpm-lock.yaml'
git commit -m 'chore: remove dependency lockfile change'
git pushIf this PR intentionally needs a dependency graph change, ask a repository admin or member of The action will approve the current head SHA ( |
775895c to
eabac26
Compare
|
Codex review: needs maintainer review before merge. Reviewed July 2, 2026, 10:07 PM ET / 02:07 UTC. Summary PR surface: Tests +79, Config 0, Other 0. Total +79 across 4 files. Reproducibility: not applicable. this is a test coverage and dependency update PR, not a bug report. Source and package inspection show current main uses Crabline 0.1.7, while 0.1.8 is the inspected package version with the Zalo server and bridge path the new test covers. Review metrics: 1 noteworthy metric.
Stored data model Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Keep the focused QA Lab Zalo coverage and Crabline 0.1.8 bump, then merge only after secops/admin dependency approval and required checks are settled. Do we have a high-confidence way to reproduce the issue? Not applicable: this is a test coverage and dependency update PR, not a bug report. Source and package inspection show current main uses Crabline 0.1.7, while 0.1.8 is the inspected package version with the Zalo server and bridge path the new test covers. Is this the best way to solve the issue? Yes, conditionally: adding the focused case to the existing Crabline transport test is the narrowest code shape because the QA Lab adapter already delegates channel-specific behavior to Crabline. The better merge path question is process-related: secops/admin must approve the dependency graph update first. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 3ad465d32b3b. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Tests +79, Config 0, Other 0. Total +79 across 4 files. View PR surface stats
Security concerns:
Acceptance criteria:
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
eabac26 to
81b14d3
Compare
Summary
@openclaw/[email protected]sendMessageendpoint and assert recorder-backed QA outbound normalizationNo additional QA runtime or Zalo channel wiring is required: the existing generic Crabline transport consumes the released Zalo bridge.
Stack
ZALO_API_URLendpoint seamTests
pnpm install --frozen-lockfilenode scripts/run-vitest.mjs extensions/qa-lab/src/crabline-transport.test.ts(14 tests passed)pnpm format:check extensions/qa-lab/src/crabline-transport.test.ts extensions/qa-lab/package.json pnpm-workspace.yamlgit diff --check.agents/skills/autoreview/scripts/autoreview --mode local --stream-engine-output(clean, no actionable findings)