Skip to content

fix(ci): restore channel import guardrails#49378

Closed
neeravmakwana wants to merge 3 commits into
openclaw:mainfrom
neeravmakwana:fix/channel-import-guardrails-rerun
Closed

fix(ci): restore channel import guardrails#49378
neeravmakwana wants to merge 3 commits into
openclaw:mainfrom
neeravmakwana:fix/channel-import-guardrails-rerun

Conversation

@neeravmakwana

Copy link
Copy Markdown
Contributor

Summary

AI-assisted: yes (Cursor). Testing: partially blocked by unrelated upstream validation failures.

  • Problem: latest main still leaves src/plugin-sdk/channel-import-guardrails.test.ts red after the recent plugin-sdk seam refactors.
  • Why it matters: the CI guardrail is supposed to enforce public extension seams, but current entrypoints and contract wiring still leak private extensions/*/src/* imports or trip a false-positive regex.
  • What changed: moved the remaining line, nostr, and synology-chat setup exports onto public setup-entry.js seams; updated the Matrix contract registry to use the public extensions/matrix/index.js seam; tightened the extension-to-extension regex so core ../../../src/... imports are not misclassified as sibling-extension imports.
  • What did NOT change (scope boundary): no channel runtime behavior, message delivery logic, or media/transcript behavior changed.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

User-visible / Behavior Changes

None.

Security Impact (required)

  • New permissions/capabilities? (Yes/No) No
  • Secrets/tokens handling changed? (Yes/No) No
  • New/changed network calls? (Yes/No) No
  • Command/tool execution surface changed? (Yes/No) No
  • Data access scope changed? (Yes/No) No
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS: macOS 26.3.0 (Darwin 25.3.0)
  • Runtime/container: Node 24 + pnpm + Bun/Vitest
  • Model/provider: N/A
  • Integration/channel (if any): LINE, Matrix, Nostr, Synology Chat
  • Relevant config (redacted): none

Steps

  1. Check out latest main.
  2. Run bunx vitest run --config vitest.unit.config.ts src/plugin-sdk/channel-import-guardrails.test.ts.
  3. Observe current failures around private extension seams like src/plugin-sdk/line.ts, src/plugin-sdk/nostr.ts, src/channels/plugins/contracts/registry.ts, plus a false-positive extension-to-extension regex hit.

Expected

  • The guardrail suite passes while core/plugin-sdk code only imports approved extension public seams.

Actual

  • The guardrail suite fails on latest main because a few remaining core entrypoints still import extensions/*/src/* directly and one regex still misclassifies core ../../../src/... imports.

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios: bunx vitest run --config vitest.unit.config.ts src/plugin-sdk/channel-import-guardrails.test.ts passes after this change.
  • Edge cases checked: confirmed the remaining core entrypoints now use approved setup-entry.js/index.js seams and the regex no longer flags core ../../../src/... imports as sibling-extension imports.
  • What you did not verify: live channel flows; this PR only changes import wiring and guardrail coverage.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

  • Backward compatible? (Yes/No) Yes
  • Config/env changes? (Yes/No) No
  • Migration needed? (Yes/No) No
  • If yes, exact upgrade steps:

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: revert commit 3ac6419e9.
  • Files/config to restore: the touched setup-entry.ts, src/plugin-sdk/*.ts, and src/channels/plugins/contracts/registry.ts files.
  • Known bad symptoms reviewers should watch for: guardrail regressions or build-time unresolved imports in plugin-sdk/contract code.

Risks and Mitigations

  • Risk: one of the replacement public seams could be incomplete for a setup export.
  • Mitigation: the dedicated channel import guardrail suite passes after the change.

Unrelated Validation Failures

These came from untouched upstream files and are not caused by this 8-file diff:

  • pnpm build currently fails in extensions/tlon/src/monitor/media.ts with an unresolved ../api.js import.
  • pnpm check currently fails on existing formatting drift in untouched extensions/mattermost/src/* and extensions/tlon/src/* files.
  • I also re-ran pnpm test, but the repo's node scripts/test-parallel.mjs wrapper did not produce a final summary before hanging in this environment, so I am not claiming a full-suite pass here.

Made with Cursor

@openclaw-barnacle openclaw-barnacle Bot added channel: line Channel integration: line channel: nostr Channel integration: nostr size: XS labels Mar 18, 2026
@greptile-apps

greptile-apps Bot commented Mar 18, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR restores CI guardrails for channel import boundaries by redirecting three plugin-sdk files (line.ts, nostr.ts, synology-chat.ts) and the Matrix contract registry away from private extensions/*/src/* paths onto approved public seams (setup-entry.js / index.js), and tightens the extension-to-extension regex in the guardrail test to eliminate false positives on deep core ../../../src/... paths.

Key changes:

  • src/plugin-sdk/{line,nostr,synology-chat}.ts — swap private-src imports for the corresponding public setup-entry.js barrel.
  • extensions/{line,nostr,synology-chat}/setup-entry.ts — expose the setup adapter/wizard symbols as named re-exports so they satisfy the public-seam contract.
  • src/channels/plugins/contracts/registry.ts — import setMatrixRuntime via extensions/matrix/index.js instead of extensions/matrix/src/runtime.js; the index barrel already re-exports this symbol.
  • channel-import-guardrails.test.ts — the regex (?:\.\.\/)+(?!src\/)[A-Za-z0-9][^/"']*\/src\/ correctly anchors on an alphanumeric directory name, preventing .. from being misidentified as a sibling extension name in paths like ../../../src/….

One minor style observation: the three setup-entry.ts files each add an import statement for symbols that are only re-exported via export { X } from "...". The local binding created by the import is never consumed within the file and can be dropped — see the inline comment on extensions/line/setup-entry.ts for details; the same applies to extensions/nostr/setup-entry.ts and extensions/synology-chat/setup-entry.ts.

Confidence Score: 5/5

  • This PR is safe to merge — it is a pure import-path correction with no runtime behavior changes.
  • All changed symbols remain the same across the indirection layer (public barrel simply re-exports the same private values), the regex tightening is analytically correct and verified by the passing guardrail suite, and no logic, configuration, or API surface changed. The only finding is redundant import statements in three setup-entry files, which is harmless at runtime.
  • No files require special attention.
Prompt To Fix All With AI
This is a comment left during a code review.
Path: extensions/line/setup-entry.ts
Line: 3-4

Comment:
**Redundant import statements alongside re-exports**

`lineSetupAdapter` and `lineSetupWizard` are imported on lines 3–4 but never used directly in module logic — they're only re-exported via `export { ... } from "..."` on lines 7–8. In ESM (and TypeScript), `export { X } from "./module"` creates the re-export binding directly without needing a prior `import` of the same name. These import statements create unused local bindings and can be safely removed.

The same redundant pattern exists in `extensions/nostr/setup-entry.ts` line 3 (`nostrSetupAdapter, nostrSetupWizard`) and `extensions/synology-chat/setup-entry.ts` line 3 (`synologyChatSetupAdapter, synologyChatSetupWizard`).

```suggestion
import { defineSetupPluginEntry } from "openclaw/plugin-sdk/core";
import { lineSetupPlugin } from "./src/channel.setup.js";

```

How can I resolve this? If you propose a fix, please make it concise.

Last reviewed commit: "fix(ci): restore cha..."

Comment thread extensions/line/setup-entry.ts Outdated

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: df21369640

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment thread src/plugin-sdk/line.ts Outdated
@neeravmakwana

Copy link
Copy Markdown
Contributor Author

Addressed the AI review feedback.

What changed:

  • removed the redundant local imports in extensions/line/setup-entry.ts, extensions/nostr/setup-entry.ts, and extensions/synology-chat/setup-entry.ts
  • while validating that cleanup, I found it exposed a line setup-entry cycle in the contracts lane
  • switched src/plugin-sdk/{line,nostr,synology-chat}.ts to use small dedicated public setup-api.js seams instead of setup-entry.js, which keeps the public-seam guardrail intact without the cycle
  • resolved the Greptile review thread after pushing the fix

CI note:

  • the specific broken check this PR is intended to fix is checks (node, contracts, pnpm test:contracts)
  • I confirmed from that job's failing log that it was breaking in the line seam path (buildChannelConfigSchema is not a function via src/plugin-sdk/line.ts -> extensions/line/setup-entry.ts)
  • this PR does not address unrelated upstream failures like the current secrets check or the unrelated local tlon build / formatting drift I mentioned earlier

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5d9485fb8a

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment thread extensions/line/setup-entry.ts
@neeravmakwana

Copy link
Copy Markdown
Contributor Author

Follow-up on the two Codex review comments:

  • the earlier P0 cycle concern is already addressed in the current branch
  • src/plugin-sdk/line.ts, src/plugin-sdk/nostr.ts, and src/plugin-sdk/synology-chat.ts no longer re-export setup symbols from setup-entry.js
  • they now use dedicated setup-api.ts seams instead, which avoids the setup-entry.ts -> channel.setup.ts -> api.ts initialization cycle while still keeping the guardrail on a public extension seam
  • setup-entry.ts remains responsible only for the setup plugin entry itself, so src/channels/plugins/bundled.ts can still import the named setup plugin export without breaking onboarding/setup flows

I resolved both review threads because the current branch no longer has the setup-entry.js re-export pattern that triggered those comments.

@openclaw-barnacle

Copy link
Copy Markdown

Please don't make PRs for test failures on main.

The team is aware of those and will handle them directly on the codebase, not only fixing the tests but also investigating what the root cause is. Having to sift through test-fix-PRs (including some that have been out of date for weeks...) on top of that doesn't help. There are already way too many PRs for humans to manage; please don't make the flood worse.

Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

channel: line Channel integration: line channel: nostr Channel integration: nostr r: no-ci-pr Auto-close: PR only chasing known main CI/test failures. size: XS

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants