Contract tests stop timing out on Slack and Discord directories

hxy91819

·Apr 12, 2026·#65280tests(contracts): use contract-api for Slack and Discord directories

The Slack and Discord directory contract tests were timing out because the shared test helper loaded the full plugin APIs when it only needed a couple of config-backed directory functions. Narrower contract surfaces now let those tests complete.

The Slack and Discord directory contract tests were timing out in the CI contracts pipeline. The root cause was a mismatch between what the shared contract helper needed and what it was importing — the helper was loading entire plugin API surfaces when it only needed two config-backed directory listing functions per plugin.

The fix creates narrower public seams. Both the Slack and Discord plugins now export their config-backed directory functions through dedicated surfaces, separate from the full plugin APIs. The shared test helper was updated to load these narrower surfaces instead of the full plugin graphs. The same directory assertions run through a more targeted import path.

No runtime behavior changed. The full plugin APIs still work as before — this is purely a test infrastructure fix that lets the contracts CI lane complete without timing out.

View Original GitHub Description

Summary

CI pipeline: checks-fast-contracts-protocol
Failing problem: src/channels/plugins/contracts/plugins-core-extension.slack.contract.test.ts -> lists peers/groups from config
Failing problem: src/channels/plugins/contracts/plugins-core-extension.discord.contract.test.ts -> lists peers/groups from config (numeric ids only)
Problem: the shared plugins-core extension contract helper synchronously loaded the full Slack and Discord api.ts surfaces just to reach config-backed directory listing helpers
Why it matters: those broader imports made the Slack and Discord directory contract tests slow enough to time out in the contracts lane
What changed: export the config-backed directory listing helpers from each plugin's contract-api.ts, then have the shared contract helper load those narrower contract surfaces instead of the full plugin APIs
What did NOT change (scope boundary): runtime directory behavior, account-merging logic, and the public api.ts surfaces used by real runtime callers

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes #
Related #64154
This PR fixes a bug or regression

Root Cause (if applicable)

Root cause: the shared channel contract helper used loadBundledPluginApiSync(...) for Slack and Discord directory assertions, even though the tests only needed config-backed directory functions
Missing detection / guardrail: those directory functions were not exported on the narrower contract-api.ts surface, so the helper had to pull in the full plugin API surface
Contributing context (if known): the contracts lane runs these directory suites alongside many other contract tests, so excess import cost turned into job-level timeouts

Regression Test Plan (if applicable)

Coverage level that should have caught this:
- Unit test
- Seam / integration test
- End-to-end test
- Existing coverage already sufficient
Target test or file: src/channels/plugins/contracts/plugins-core-extension.slack.contract.test.ts, src/channels/plugins/contracts/plugins-core-extension.discord.contract.test.ts
Scenario the test should lock in: config-backed directory contract coverage can load Slack and Discord through a narrow public contract seam without timing out
Why this is the smallest reliable guardrail: the regression lived at the public-surface loading boundary shared by both contract suites
Existing test that already covers this (if any): these two contract files are the direct regression coverage
If no new test is added, why not: existing contract tests already capture the failure once they load the right public seam

User-visible / Behavior Changes

None.

Diagram (if applicable)

Before:
contract helper -> loadBundledPluginApiSync("slack"/"discord") -> full api.ts graph
=> directory contract tests spend too long importing and time out in contracts CI

After:
contract helper -> loadBundledPluginContractApiSync("slack"/"discord") -> contract-api.ts
contract-api.ts -> directory-config helpers
=> same directory assertions run through a narrower public seam

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: Linux
Runtime/container: Node 22 / pnpm workspace
Model/provider: N/A
Integration/channel (if any): Slack, Discord
Relevant config (redacted): config-only directory fixtures in contract tests

Steps

Run pnpm exec vitest run -c test/vitest/vitest.contracts.config.ts src/channels/plugins/contracts/plugins-core-extension.slack.contract.test.ts src/channels/plugins/contracts/plugins-core-extension.discord.contract.test.ts
Observe the shared directory contract helper loading Slack and Discord public surfaces
Confirm both contract files finish successfully in the contracts lane

Expected

Slack and Discord config-backed directory contract tests complete without timing out.

Actual

Before this change, both suites timed out in the contracts pipeline because the helper imported the heavier api.ts surfaces.

Evidence

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

Human Verification (required)

Verified scenarios: Slack and Discord directory contract suites both pass through test/vitest/vitest.contracts.config.ts after switching to contract-api
Edge cases checked: the helper still keeps API-surface type assertions for SlackProbe, DiscordProbe, and token-resolution types while loading directory functions from the narrower contract seam
What you did not verify: the full contracts suite end-to-end

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.

Compatibility / Migration

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

Risks and Mitigations

Risk: other contract helpers could still load broader plugin surfaces than they need
- Mitigation: this PR moves Slack and Discord directory coverage onto explicit contract-api exports, which is the narrow seam reviewers can apply elsewhere if needed