Skip to content

fix: try to fix two flaky tests - #712

Open
MathyV wants to merge 1 commit into
bulwarkmail:mainfrom
MathyV:fix-tests
Open

fix: try to fix two flaky tests#712
MathyV wants to merge 1 commit into
bulwarkmail:mainfrom
MathyV:fix-tests

Conversation

@MathyV

@MathyV MathyV commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

Summary

I noticed while developing the other PR. These tests don't fail every time, heavy CPU usage causes them to fail more often since it is more a timing issue then anything else.

Changes

  • The keep-alive test used the same Response object for all fetch calls, so depending on the timing, a second call either failed or not. Now each call gets its own Response object.
  • The config route test wrote the session-secret file into the working directory but didn't wait for the unlink to complete, so the file could outlive the test. It is put into the temp directory now and properly removed.

Related issues

None

Type of change

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update
  • Refactor / code quality improvement
  • Chore / dependency update / CI change

Checklist

  • I have read the Contributing Guide
  • My code follows the project's code style and conventions
  • I have run npm run typecheck && npm run lint and there are no errors
  • The build passes (npm run build)
  • I have tested my changes locally
  • I have added or updated documentation if needed
  • I have updated translations (locales/) if my changes affect user-facing text
  • I have included screenshots or a screen recording for UI changes

Screenshots / demo

None

Notes for reviewers

None

These tests don't fail every time, heavy CPU usage causes them to fail more
often since it is more a timing issue then anything else.

The keep-alive test used the same Response object for all fetch calls, so
depending on the timing, a second call either failed or not. Now each call gets
its own Response object.

The config route test wrote the session-secret file into the working directory
but didn't wait for the unlink to complete, so the file could outlive the test.
It is put into the temp directory now and properly removed.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Pull request overview

This PR aims to reduce Vitest flakiness in the JMAP client resilience suite and the config route suite by eliminating shared/lingering test state (reused Response bodies, keep-alive timers, and a shared working-directory secret file).

Changes:

  • Adjusts the JMAP resilience tests to return a fresh Response per mocked fetch call for keep-alive scenarios.
  • Adds explicit teardown of connected JMAP clients between tests to prevent keep-alive intervals from leaking across tests.
  • Moves the config route test’s SESSION_SECRET_FILE to a temp directory and removes it deterministically during teardown.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
lib/tests/jmap-client-resilience.test.ts Improves fetch mocking and adds teardown intended to prevent keep-alive timer leakage.
lib/tests/config-route.test.ts Uses a temp-backed secret file and synchronous cleanup to prevent cross-test filesystem leakage.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines 53 to 60
afterEach(() => {
// Connecting starts a keep-alive interval that outlives the test unless it
// is stopped here, and its ping then consumes a later test's mocked fetch.
connectedClients.forEach((client) => client.disconnect());
connectedClients.length = 0;
fetchSpy.mockRestore();
vi.useRealTimers();
});
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants