Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix test(cli): qr-cli.test.ts fails with ReferenceError due to vitest mock hoisting [3 pull requests, 2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#73177•Fetched 2026-04-29 06:22:35
View on GitHub
Comments
2
Participants
2
Timeline
9
Reactions
1
Author
DoncicXDoncicX
Participants
DoncicXDoncicXiot2edgeiot2edge
Timeline (top)
cross-referenced ×4commented ×2closed ×1mentioned ×1

src/cli/qr-cli.test.ts fails deterministically with a ReferenceError: Cannot access '__vi_import_2__' before initialization when the module import chain includes ../logging/subsystem.js.

This is a pre-existing vitest mock hoisting bug that becomes exposed when any file in the same import graph adds a new dependency on logging/subsystem.

Error Message

Error: [vitest] There was an error when mocking a module. If you are using "vi.mock" factory, make sure there are no top level variables inside, since this call is hoisted to top of the file. Read more: https://vitest.dev/api/vi.html#vi-mock
Caused by: ReferenceError: Cannot access '__vi_import_2__' before initialization
 ❯ src/cli/qr-cli.test.ts:21:3
 ❯ src/logging/subsystem.ts:5:1
 ❯ src/security/windows-acl.ts:4:1
 ❯ src/security/audit-fs.ts:2:1
 ❯ src/secrets/resolve.ts:13:1
 ❯ src/gateway/auth-config-utils.ts:4:1
 ❯ src/pairing/setup-code.ts:5:1
 ❯ src/cli/qr-cli.test.ts:3:1

Root Cause

qr-cli.test.ts defines top-level variables (e.g. runtime from createCliRuntimeCapture()) and then references them inside vi.mock() factory functions.

Because vi.mock() is hoisted to the top of the file by vitest, those top-level variables have not yet been initialized when the factory runs. Normally this test passes because the import chain during initialization does not trigger the mock factory early. However, any change that introduces a new module dependency into the import graph (such as adding import { createSubsystemLogger } from "../logging/subsystem.js" to windows-acl.ts) alters the initialization order and causes the hoisted mock factory to execute before its captured variables are ready.

Fix Action

Fixed

PR fix notes

PR #73206: fix(test): resolve vitest mock hoisting in qr-cli.test.ts

Description (problem / solution / changelog)

Fixes #73177

The vi.mock() factory in qr-cli.test.ts references top-level variables (runtime, runtimeLog, runtimeError, runtimeExit, resetRuntimeCapture) which are not yet initialized when vitest hoists the mock to the top of the file.

This change moves those declarations into vi.hoisted() so they are available before the mock factory executes.

Also updated runtime destructuring to preserve the same variable names used throughout the test file.

Changed files

  • src/cli/qr-cli.test.ts (modified, +1/-1)
  • src/cli/run-main.exit.test.ts (modified, +1/-0)

PR #72782: fix(security): replace console.warn with structured logger in windows…

Description (problem / solution / changelog)

Replaces the console.warn in resolveCurrentUserSid with createSubsystemLogger("security/windows-acl"), resolving the existing TODO about noisy console output on constrained Windows hosts.

Motivation The previous console.warn in the resolveCurrentUserSid catch block was explicitly marked with a TODO noting that it can be noisy on constrained Windows hosts (e.g. strict output-capture environments or CI runners with limited stdio). Using a structured logger allows the output to be filtered by log level and subsystem, eliminating unwanted stderr noise in quiet / CI modes.

Changes

  • Import createSubsystemLogger from ../logging/subsystem.js
  • Add module-level logger createSubsystemLogger("security/windows-acl")
  • Replace console.warn(...) with logger.warn(...) in resolveCurrentUserSid
  • Remove the TODO comment (now resolved)

Testing

  • Existing windows-acl.test.ts already covers the whoami failure path (returns null silently)
  • No behavioral change — SID resolution remains best-effort; only the logging mechanism changes

Changed files

  • src/security/windows-acl.ts (modified, +4/-4)

PR #73326: fix(test): resolve vitest mock hoisting in logs-cli.test.ts to prevent cascade CI failure

Description (problem / solution / changelog)

Fixes #73324

src/cli/logs-cli.test.ts uses the same pre-existing vitest mock hoisting pattern that caused #73177 (qr-cli.test.ts). Top-level const declarations for mock functions (callGatewayFromCli, readConfiguredLogTail, buildGatewayConnectionDetails) are referenced inside vi.mock() factory functions. When vitest hoists those factories to the top of the file, the variables are not yet initialized, which produces ReferenceError: Cannot access '__vi_import_X__' before initialization when the module dependency graph shifts (e.g. any future change that alters the import chain of ../gateway/call.js, ../logging/log-tail.js, or ./gateway-rpc.js).

Changes

  • Move the three mock function declarations into vi.hoisted() so they are available before the vi.mock() factories execute, following the same pattern used in #73206.
  • Zero runtime / business-logic change; test-only fix.

Impact

  • Prevents a future CI cascade failure similar to #73177.
  • All existing tests in logs-cli.test.ts continue to pass.

Changed files

  • src/cli/logs-cli.test.ts (modified, +40/-125)

Code Example

Error: [vitest] There was an error when mocking a module. If you are using "vi.mock" factory, make sure there are no top level variables inside, since this call is hoisted to top of the file. Read more: https://vitest.dev/api/vi.html#vi-mock
Caused by: ReferenceError: Cannot access '__vi_import_2__' before initialization
 ❯ src/cli/qr-cli.test.ts:21:3
 ❯ src/logging/subsystem.ts:5:1
 ❯ src/security/windows-acl.ts:4:1
 ❯ src/security/audit-fs.ts:2:1
 ❯ src/secrets/resolve.ts:13:1
 ❯ src/gateway/auth-config-utils.ts:4:1
 ❯ src/pairing/setup-code.ts:5:1
 ❯ src/cli/qr-cli.test.ts:3:1
RAW_BUFFERClick to expand / collapse

Summary

src/cli/qr-cli.test.ts fails deterministically with a ReferenceError: Cannot access '__vi_import_2__' before initialization when the module import chain includes ../logging/subsystem.js.

This is a pre-existing vitest mock hoisting bug that becomes exposed when any file in the same import graph adds a new dependency on logging/subsystem.

Error

Error: [vitest] There was an error when mocking a module. If you are using "vi.mock" factory, make sure there are no top level variables inside, since this call is hoisted to top of the file. Read more: https://vitest.dev/api/vi.html#vi-mock
Caused by: ReferenceError: Cannot access '__vi_import_2__' before initialization
 ❯ src/cli/qr-cli.test.ts:21:3
 ❯ src/logging/subsystem.ts:5:1
 ❯ src/security/windows-acl.ts:4:1
 ❯ src/security/audit-fs.ts:2:1
 ❯ src/secrets/resolve.ts:13:1
 ❯ src/gateway/auth-config-utils.ts:4:1
 ❯ src/pairing/setup-code.ts:5:1
 ❯ src/cli/qr-cli.test.ts:3:1

Root cause

qr-cli.test.ts defines top-level variables (e.g. runtime from createCliRuntimeCapture()) and then references them inside vi.mock() factory functions.

Because vi.mock() is hoisted to the top of the file by vitest, those top-level variables have not yet been initialized when the factory runs. Normally this test passes because the import chain during initialization does not trigger the mock factory early. However, any change that introduces a new module dependency into the import graph (such as adding import { createSubsystemLogger } from "../logging/subsystem.js" to windows-acl.ts) alters the initialization order and causes the hoisted mock factory to execute before its captured variables are ready.

Reproduction

  1. Add import { createSubsystemLogger } from "../logging/subsystem.js" to src/security/windows-acl.ts
  2. Run pnpm vitest run src/cli/qr-cli.test.ts
  3. Observe the __vi_import_2__ initialization error

Suggested fix

Refactor qr-cli.test.ts so that variables referenced inside vi.mock() factories are created via vi.hoisted() instead of top-level const declarations, ensuring they are available when the mock factory executes.

Affected CI jobs

  • checks-node-agentic-commands
  • checks-node-core (indirectly, when the test suite includes this file)

extent analysis

TL;DR

Refactor qr-cli.test.ts to use vi.hoisted() for variables referenced inside vi.mock() factories to ensure they are initialized before the mock factory executes.

Guidance

  • Identify all top-level variables in qr-cli.test.ts that are referenced inside vi.mock() factories, such as runtime from createCliRuntimeCapture().
  • Replace these top-level variables with vi.hoisted() to ensure they are available when the mock factory executes.
  • Verify that the import chain no longer triggers the mock factory early by checking the initialization order of the modules.
  • Test the refactored code by running pnpm vitest run src/cli/qr-cli.test.ts to ensure the __vi_import_2__ initialization error is resolved.

Example

// Before
const runtime = createCliRuntimeCapture();
vi.mock('./some-module', () => ({
  // referencing runtime here will cause the error
  someFunction: () => runtime.doSomething(),
}));

// After
const runtime = vi.hoisted(() => createCliRuntimeCapture());
vi.mock('./some-module', () => ({
  someFunction: () => runtime.doSomething(),
}));

Notes

This fix assumes that the issue is solely caused by the hoisting of vi.mock() factories in qr-cli.test.ts. If the issue persists after refactoring, further investigation into the import chain and initialization order may be necessary.

Recommendation

Apply the suggested fix by refactoring qr-cli.test.ts to use vi.hoisted() for variables referenced inside vi.mock() factories, as this directly addresses the root cause of the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#network issue#logging issue#authentication issue#prompt issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING