Skip to content

Bug: Flaky Test in ActionItemModal.spec.tsx - Passes Locally, Fails in CI #6235

@chauhan-varun

Description

@chauhan-varun

Describe the bug

The test should execute volunteer chip click logic when isVolunteerChipDisabled is false in ActionItemModal.spec.tsx fails intermittently in CI but passes consistently on local machines. This is a race condition caused by timing differences between local development environments and CI runners.

Blocking PRs: #6226, #6223, #6179

To Reproduce

Steps to reproduce the behavior:

  1. Push any change that triggers CI for the ActionItemModal test file
  2. Wait for the CI pipeline to run the test suite
  3. Observe that the test should execute volunteer chip click logic when isVolunteerChipDisabled is false fails with error:
    TestingLibraryElementError: Unable to find an element by: [data-testid="volunteerGroupSelect"]
    
  4. Run the same test locally with npm test -- --run src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx - it passes

Expected behavior

The test should pass consistently in both local and CI environments. When clicking the volunteerGroupChip, the component should switch assignmentType state to 'volunteerGroup', causing volunteerGroupSelect to render.

Actual behavior

In CI, clicking volunteerGroupChip does not trigger the expected state change before the test tries to find volunteerGroupSelect. The element never appears, and the test times out.

Error output:

× Partially Covered Lines Test Coverage > Line 515: if (!isVolunteerChipDisabled) > should execute volunteer chip click logic when isVolunteerChipDisabled is false 1296ms
  → Unable to find an element by: [data-testid="volunteerGroupSelect"]

Root Cause Analysis

1. GraphQL Mock Timing Issue

The test uses Apollo's MockedProvider with newData functions for GET_EVENT_VOLUNTEERS and GET_EVENT_VOLUNTEER_GROUPS queries:

{
  request: { query: GET_EVENT_VOLUNTEERS, ... },
  newData: () => ({ data: { event: { volunteers: [...] } } }),
}

These queries need to resolve before the component is ready for user interactions.

2. Missing Category Selection Step

The failing test was missing a crucial step that exists in similar passing tests (line 4190-4241). The passing test selects a category before clicking volunteer chips:

// This step was MISSING in the failing test
const categorySelect = screen.getByTestId('categorySelect');
await userEvent.click(categoryInput);
await userEvent.type(categoryInput, 'Category 1');

Category selection provides necessary "settle time" for GraphQL queries to resolve.

3. CI vs Local Timing Differences

Environment Query Resolution Time Result
Local ~10-50ms GraphQL data ready before chip click
CI ~100-500ms Chip clicked before data loads

CI runners (GitHub Actions VMs) are 2-3x slower than local development machines, causing the component to be in an unstable state when the test interacts with it.

4. Component Conditional Rendering

The component only renders volunteer selects after GraphQL data loads:

{assignmentType === 'volunteer' && (<Autocomplete data-testid="volunteerSelect" />)}
{assignmentType === 'volunteerGroup' && (<Autocomplete data-testid="volunteerGroupSelect" />)}

Without data, clicking chips doesn't trigger the expected re-render.

Solution

The fix adds:

  1. Category selection step before interacting with chips (matching the pattern of passing tests)
  2. Explicit waits for volunteerSelect to appear before clicking chips
  3. Longer timeouts ({ timeout: 5000 }) to handle CI slowness
// Wait for dialog
await waitFor(() => {
  expect(screen.getByRole('dialog')).toBeInTheDocument();
});

// Select a category first (required for volunteer functionality)
const categorySelect = screen.getByTestId('categorySelect');
const categoryInput = within(categorySelect).getByRole('combobox');
await userEvent.click(categoryInput);
await userEvent.type(categoryInput, 'Category 1');
await waitFor(async () => {
  const option = await screen.findByText('Category 1');
  await userEvent.click(option);
});

// Wait for volunteer select to be in the document
await waitFor(() => {
  expect(screen.getByTestId('volunteerSelect')).toBeInTheDocument();
});

// NOW it's safe to click chips

Additional details

File affected: src/screens/OrganizationActionItems/ActionItemModal/ActionItemModal.spec.tsx

Test location: Line ~4098-4164 (in describe('Line 515: if (!isVolunteerChipDisabled)'))

Similar passing test: Line 4190-4241 (should execute volunteer group chip click logic when isVolunteerGroupChipDisabled is false) - which correctly selects a category first

CI Run Examples:

Metadata

Metadata

Assignees

Labels

bugSomething isn't workinggood first issueGood for newcomerstestTesting applicationui/uxissue related and being worked with the figma file of the Admin UI

Type

No type

Projects

Status

Done

Status

Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions