Parallel analysis lane
Context: The repo recently migrated to Vitest 4 (vitest 4.1.8). The production code is considered correct; these are TEST-ONLY breakages from Vitest 4 behavior changes. Known Vitest 4 changes that cause failures:
vi.fn()mocks whose implementation is an arrow function can no longer be invoked withnew("The vi.fn() mock did not use 'function' or 'class' in its implementation"). Fix by giving the mock afunctionorclassimplementation.- Module mock factory/hoisting semantics and spy behavior changed slightly.
Your assigned failing files (paths relative to /home/akitav2/projects/4626/frontend):
- api/tests/imageGenerationRoutes.test.ts — 12 failures
- api/tests/tokenImageImportSafety.test.ts — 1 failure
- api/tests/walletEndpointsHardening.test.ts — 2 failures
- api/tests/walletConfirmOwner.test.ts — 1 failure
Instructions:
- Work in /home/akitav2/projects/4626/frontend.
- For each file: run
npx vitest run <file>to see failures, diagnose, fix the TEST file (preserve test intent and assertion strength — do not weaken, delete, or skip tests). Only modify production source if the failure is unambiguously test-infrastructure related and unfixable in the test, and explain why. - Note: the premium token icon renderer under api/_handlers/token/renderers/ is production-stable; do not rewrite it. If imageGenerationRoutes failures involve Sharp or renderer internals, fix at the mock/test level.
- Do NOT touch anything under server/_lib/arena/ (another session is actively editing it).
- Do NOT run the full test suite; only run your assigned files.
- Re-run each fixed file until green.
Final response: for each file, report root cause, what you changed, and final pass/fail status.
Analysis
I'll run the failing tests to see what's going wrong.
Tools invoked: UpdateCurrentStep, Shell
Analysis
The tests are returning 401 errors when they shouldn't be, which suggests the auth mock isn't set up correctly — probably an issue with how the mock factory is configured. I should check the test file to see what's going on.
Tools invoked: Read
Analysis
Let me check the vitest config and see the full failure list.
I'm realizing the 401 errors in tests are stemming from how the session mock is set up across different test blocks. The mock is initialized in vi.hoisted to return the address by default, but the beforeEach hook that clears mocks and sets the return value only exists in the first describe block, so other blocks aren't getting the same setup. I need to figure out whether vi.clearAllMocks() in Vitest 4 is clearing the implementations or just the call records. I see the real issue now — in Vitest 4, mockReturnValue(null) set in one test persists across all subsequent tests because there's no beforeEach resetting it between describes. The test at line 226 that explicitly sets mockReturnValue(null as any) leaves the mock returning null for every test that follows, which explains why all the later tests are getting 401 responses even when they try to set a valid session address.
I need to check the Vitest config to see if there's a mockReset or restoreMocks setting that might have handled this cleanup automatically in Vitest 3, and then look at the actual failure list to confirm which tests are failing.
Tools invoked: Shell, Glob
Analysis
The tests failing after line 225 are all using a persistent mock stub where mockReturnValue(null) is set after the initial vi.fn(impl) call, and this worked in Vitest 3 but broke in Vitest 4 due to a change where mock implementations passed directly to vi.fn() are now permanent and can't be overridden by mockReturnValue.
Tools invoked: Read
Analysis
I'm noticing a key breaking change in Vitest 4 where restoreMocks now only affects spies created with vi.spyOn, not vi.fn() mocks — whereas in Vitest 3, vi.restoreAllMocks would restore all mocks including vi.fn() by resetting them to their original implementation and clearing any mock return value overrides.
This means the persistent mockReturnValue(null) set in one test is now leaking into subsequent tests, causing 401 errors everywhere. The fix would be to add a file-level beforeEach that calls vi.resetAllMocks() to reset mocks back to their original implementation, which preserves the test's intent of persistent stubbing within a single test while ensuring clean state between tests. Adding a top-level beforeEach with vi.resetAllMocks() should work since it restores mocks to their original implementations — getSessionAddressMock back to '0xb05c...', isAdminAddressMock to false, and the resolver mocks to their defaults, which all match what the first describe block expects. I need to verify that Vitest 4's resetAllMocks actually restores the original implementation for vi.fn mocks when an implementation was provided. I think clearAllMocks and resetAllMocks still affect all mocks in V4, so I'll just test the fix empirically. Let me add the top-level beforeEach hook and run the tests.I found that Vitest 4 changed how restoreMocks works—it no longer resets vi.fn() mocks, causing mock return values from early tests to leak into later ones. I'll add a beforeEach hook to reset these mocks between tests.
Tools invoked: StrReplace
Analysis
Tools invoked: Shell
Analysis
File 1 is green. Now the next two.
The first test file is passing, now moving on to check the tokenImageImportSafety test suite.
Tools invoked: UpdateCurrentStep, Shell
Analysis
Tools invoked: Read
Analysis
I'm looking at a test that's checking for specific strings in the useTokenMetadata hook source, and it's failing because buildCanonicalTokenImageUrl isn't found. This seems less like a Vitest mocking issue and more like the actual hook source has drifted — maybe the function was renamed or moved during refactoring. Let me examine the hook file directly to see what's actually there.
Tools invoked: Read
Analysis
The second test's failure is source drift, not a mock issue. Let me check the git history to confirm.
The hook's source code has changed—it no longer includes the buildCanonicalTokenImageUrl function or the API call to fetch token images from the Base chain endpoint. The test is failing because it's checking for these specific strings that have been removed. It looks like the hook was refactored to drop the canonical token image fallback and switch to using Dexscreener instead. This doesn't seem like a Vitest 4 issue; it's more likely that the production code has diverged from what the test expects.
Since the user says the production code is correct, I need to update the test to match the new implementation. Let me trace through the git history to see exactly when the hook changed and whether the canonical helper function still exists somewhere else in the codebase.
Tools invoked: Shell
Analysis
Tools invoked: AwaitShell
Analysis
Tools invoked: Read
Analysis
The rg search is taking too long, probably getting bogged down in large directories. I'll switch to the Grep tool instead to speed things up.
Tools invoked: Shell
Analysis
Tools invoked: Grep, AwaitShell
Analysis
Tools invoked: Shell
Analysis
Tools invoked: Shell
Analysis
I see that production intentionally switched from buildCanonicalTokenImageUrl to Dexscreener-based fallbacks through a series of commits, so the test is checking stale assertions. I need to update the test to match the current implementation while keeping the same guard in place—verifying that the contractURI wiring and image fallback mechanism are both functioning as intended.
The fix involves keeping the name: 'contractURI' and refetchContractURI assertions intact, swapping out buildCanonicalTokenImageUrl for resolveDexscreenerTokenImageUrl, and updating the expected URL string to match what's actually in the Dexscreener resolver—the https://api.dexscreener.com/latest/dex/tokens/ endpoint. This preserves the test's original intent of asserting both the fallback function name and its fetch URL.I found that production intentionally uses a Dexscreener-based token image fallback instead of the canonical one, and the test is checking outdated source strings. I'll update the assertions to match the current intended behavior.
Tools invoked: StrReplace
Analysis
Tools invoked: Shell
Analysis
Tools invoked: Shell
Analysis
Tools invoked: Read
Analysis
Looking at the test failures, setCanonical is returning 404 instead of the expected 429 rate-limit response, and the sweep process has the same issue. I need to check which rate-limit module these handlers are actually using — they might be importing from @4626/server-core or from the local server/_lib/infra/rateLimit.js, and the mocks should cover both paths. The 404 response suggests the handler might be returning that when a feature is disabled or something else is happening before the rate-limit check.
Looking at the test setup, it's mocking readRequestPrincipalAddressMock and setting checkRateLimitMock to return {allowed:false}, which should trigger the rate-limit response. But I'm wondering if there's a Vitest 4 behavior change with vi.clearAllMocks() — though it should only clear call history, not implementations. The beforeEach sets up persistent mock return values for each test, so that should be fine. The handler module might be cached differently, but the test doesn't use vi.resetModules() so that's probably not it either.
Let me trace through the setCanonical handler to see what's actually happening.
Tools invoked: Read
Analysis
I'm looking at a test for the 429 rate limit response, but it's getting a 404 instead, which suggests the rate limit check is passing when it shouldn't be. The test sets up mocks to return allowed: false, but something's off with how the mock overrides are stacking—the beforeEach sets a persistent return value and then the test tries to override it with mockReturnValueOnce, but that doesn't seem to be taking effect.
I'm wondering if the real checkRateLimit from @4626/server-core is being called instead of the mock, which would explain why it's allowing the request. But test #3 passed and it also uses the server-core mock, so the mock should be working. The issue might be with test ordering—test #3 queued a mockReturnValueOnce that never got consumed because the handler returned early, and now that leftover mock state is affecting test #4. So the leak pattern becomes clearer: test #3's queued {allowed:true} stub for checkRateLimit never gets consumed, and when test #4 runs, that stale once-implementation gets pulled first. Meanwhile, if Vitest 4's clearAllMocks() also wipes mock implementations (not just call history), then resolveAuthorizedRequestPrincipal loses its hoisted return value and becomes undefined, triggering the 404 instead of the expected 429. The combination of the leaked once-stub plus the cleared implementation explains the observed behavior.
The real fix is to make the test deterministic: either remove the unnecessary once-stub from test #3 since the rate limit check happens after the principal check anyway, or explicitly reset the mock queue in beforeEach rather than relying on unclear clearAllMocks() semantics.
Actually, the cleaner solution is to switch beforeEach from vi.clearAllMocks() to vi.resetAllMocks() — in Vitest 4 this resets implementations back to their originals AND clears the once-queues, so subsequent re-stubs in beforeEach still apply. That prevents leaks from unconsumed once-stubs across tests.
For the second failure, I'm tracing through the mock queue: test #3 queues an unused {allowed:true} that leaks into test #4, and the rate limit check order matters for which test consumes it. So the enqueue handler must check the principal first before rate limiting, which is why test #5 returns 401 without consuming a queue item. That means test #6 consumes the leaked {allowed:false} from test #4 and correctly gets 429. Then test #8 consumes the {allowed:true} from test #5, proceeds through the handler, and hits the mocked processSolanaSweepJobs which returns 200 — matching the observed behavior. The core issue is these unconsumed mock return values leaking between tests.
The fix is switching from vi.clearAllMocks() to vi.resetAllMocks() in beforeEach, since Vitest 4 changed how mockClear handles once-queues — mockReset clears them while mockClear doesn't. Using mockReset will reset the once implementations back to their originals and clear the queues, which is what we need.I found that mockReturnValueOnce stubs are leaking across tests because Vitest 4's vi.clearAllMocks() no longer clears queued once-implementations. I'll switch to vi.resetAllMocks() to properly clear those queues.
Tools invoked: StrReplace
Analysis
I'm verifying how vi.resetAllMocks() behaves in Vitest 4—specifically whether it restores the original implementations of mocked functions. For mocks created inline in the factory like handleOptions with vi.fn(() => false), the reset should restore that original implementation. I'm also checking that other mocked functions like syncUserWallets and the PrivyClient class methods handle the reset correctly.
Tools invoked: Shell
Analysis
Tools invoked: Shell
Analysis
Tools invoked: Read
Analysis
Test 3 is failing with a 409 instead of the expected 400 because the mock for extractDelegationFlags from test 2 is persisting — it's returning { needsBaseAppSetup: true, ... } when it shouldn't. I'm realizing that clearAllMocks in Vitest 4 might not be resetting the return values like it did in Vitest 3, where mockClear would also reset the implementation.
Looking at the Vitest 4 migration guide, the key change is that restoreMocks no longer restores vi.fn mocks — it only affects vi.spyOn spies. In Vitest 3, restoreMocks: true would run vi.restoreAllMocks() after each test, which reset everything including return values and queues. The fix is to switch from vi.clearAllMocks() to vi.resetAllMocks() in the beforeEach, which will restore the original implementation and clear the mock return values so each test starts fresh.Test 2's mock is bleeding into test 3 because Vitest 4 doesn't reset vi.fn() mocks automatically—I'll apply the same fix I used before.
Tools invoked: StrReplace
Analysis
Tools invoked: Shell
Analysis
All four files individually pass. Let me run them together as a final check, plus lint the edited files.
All four test files are passing, so now I'm running them together to catch any cross-file dependencies or conflicts, then checking the linting on the edited tests.
Tools invoked: Shell, ReadLints
Analysis
Tools invoked: UpdateCurrentStep
Analysis
All four assigned files are now green. Final report:
1. api/__tests__/imageGenerationRoutes.test.ts — ✅ 18/18 passing (was 12 failed)
Root cause: Vitest 4 changed vi.restoreAllMocks() (and the restoreMocks: true config in vitest.config.ts) to only restore vi.spyOn spies — it no longer resets vi.fn() mocks after each test. This suite relies on per-test persistent overrides like getSessionAddressMock.mockReturnValue(null) ("rejects unauthenticated callers") and mockReturnValue('0x1111…'), which under Vitest 3 were automatically rolled back by restoreMocks. Under Vitest 4 they leaked into every subsequent test, so all later tests saw a null session address and returned 401.
Change: Added a file-level beforeEach(() => { vi.resetAllMocks() }) (with an explanatory comment). In Vitest 4, mockReset restores the original implementations passed to vi.fn(impl) in the vi.hoisted block, recreating the old per-test isolation. No assertions were touched.
2. api/__tests__/tokenImageImportSafety.test.ts — ✅ 2/2 passing (was 1 failed)
Root cause: Not a mock issue — this is a source-content guard test that reads src/hooks/useTokenMetadata.ts and asserts on strings. Production commit 018837731 (and follow-ups) intentionally replaced the canonical token-image fallback (buildCanonicalTokenImageUrl → /api/v1/token/...) with a Dexscreener-based fallback (resolveDexscreenerTokenImageUrl), so the stale string assertions failed. Production is correct per instructions.
Change: Updated the guard's assertions to pin the current intended wiring: still asserts name: 'contractURI' and refetchContractURI (the ShareOFT ERC-7572 wiring the test protects), and now asserts resolveDexscreenerTokenImageUrl plus its exact fetch URL template instead of the removed canonical-endpoint strings. Assertion strength preserved (same number of string pins, same intent: contractURI + image-fallback wiring must not be dropped).
3. api/__tests__/walletEndpointsHardening.test.ts — ✅ 8/8 passing (was 2 failed)
Root cause: Same Vitest 4 restoreMocks change, manifesting through mockReturnValueOnce queues. The 401 tests queue checkRateLimitMock.mockReturnValueOnce({ allowed: true }), but those handlers return 401 before reaching the rate limiter, so the once-stub is never consumed. Under Vitest 3 the post-test restore discarded it; under Vitest 4 it leaked, so the next 429 test's rate-limit check consumed the leaked allowed: true and fell through (setCanonical → 404 "Profile not found", sweep process → 200).
Change: Replaced vi.clearAllMocks() with vi.resetAllMocks() in the existing beforeEach (with comment), which clears the leaked once-queues and restores hoisted originals before the per-test re-stubs run. No assertions changed.
4. api/__tests__/walletConfirmOwner.test.ts — ✅ 3/3 passing (was 1 failed)
Root cause: Same restore-mocks change. The 409 test sets extractDelegationFlagsMock.mockReturnValue({ needsBaseAppSetup: true, … }) persistently; in Vitest 4 it leaked into the next test, so the handler classified the mismatch error as a Base-setup conflict (409) instead of a 400.
Change: Replaced vi.clearAllMocks() with vi.resetAllMocks() in beforeEach (with comment), restoring extractDelegationFlagsMock's original () => ({}). No assertions changed.
Final verification: all four files run together → 4 files / 31 tests passed, no linter errors. No production code was modified, nothing under server/_lib/arena/ was touched, and the premium token icon renderer was not involved.
Was this page helpful?