[BUG?]: ComboboxOptions - flushSync was called from inside a lifecycle method.

[uriseroussi]

Hi there,

I believe there is a possible bug when using virtual scrolling in the Combobox component. When using virtual scrolling, I get a flushSync was called from inside a lifecycle method. React cannot flush when React is already rendering. Consider moving this call to a scheduler task or micro task. error originating from the ComboboxOptions component.

Has anyone encountered this and has a fix? Any help would be appreciated

## Error Type
Console Error

## Error Message
flushSync was called from inside a lifecycle method. React cannot flush when React is already rendering. Consider moving this call to a scheduler task or micro task.

## Code Frame
  63 |         }
  64 |       </ComboboxOptions> */}
> 65 |       <ComboboxOptions
     |       ^
  66 |         className='max-h-60 w-[--input-width] overflow-y-auto border empty:invisible'
  67 |       >
  68 |         {({ option }) => (

Next.js version: 16.0.8 (Webpack)

The error seems a bit finicky to reproduce. Depending on the options given to the combobox, and how fast one types, the error might or might not appear.

Below is a minimal example to reproduce.

Try to type numbers from 0 - 1000 quickly and randomly, and the error should be appear.

import { Combobox, ComboboxInput, ComboboxOption, ComboboxOptions } from '@headlessui/react';
import { useState } from 'react';

export type AutocompleteOption = {
  value: any;
  label: string;
};

export type AutocompleteProps = {
  options?: AutocompleteOption[];
  value?: any;
  displayValue?: ((item: any) => string);
};

const myOptions: AutocompleteOption[] = new Array(1000).fill(0).map((val, index) => {
  return {
    label: `Option ${index + 1}`,
    value: `Option ${index + 1}`
  };
});

const Autocomplete = ({
  options = myOptions,
  value,
  displayValue = (option) => option?.label,
}: AutocompleteProps) => {

  const [selected, setSelected] = useState(options.find(option => option.value === value) ?? null);
  const [query, setQuery] = useState('');

  const filtered = query === '' ? options : options.filter((option) => {
    return option.label.toLowerCase().includes(query.toLowerCase());
  });

  return (
    <Combobox
      as='div'
      value={selected}
      by='label'
      onChange={(option) => {
        setSelected(option);
      }}
      virtual={{ options: filtered }}
      onClose={() => setQuery('')}
    >
      <ComboboxInput
        displayValue={displayValue}
        onChange={(e) => setQuery(e.target.value)}
      />
      <ComboboxOptions
        className='max-h-60 w-[--input-width] overflow-y-auto border empty:invisible'
      >
        {({ option }) => (
          <ComboboxOption
            key={option.label}
            value={option}
          >
            {option.label}
          </ComboboxOption>
        )}
      </ComboboxOptions>
    </Combobox>
  );
};

export default Autocomplete;

Package versions:

"@headlessui/react": "^2.2.9"
"next": "^16.0.8"
"react": "^19.2.1"
"react-dom": "^19.2.1"
"tailwindcss": "^3.4.13"

Thanks,

Uri

[MILLERMARRU]

This looks like the same underlying class of issue the library already has a documented workaround for elsewhere, just not covered for the virtual-scrolling path yet. In combobox.tsx, the immediate + autoFocus handler wraps its flushSync(() => machine.actions.openCombobox()) in a microTask() specifically because calling flushSync while React is still mid-render throws exactly the warning you're seeing, there's a comment right above it explaining that.

The flushSync calls in handleKeyDown (Space/Enter/ArrowDown/ArrowUp/Escape) aren't wrapped the same way, because a normal keydown event handler runs outside React's render phase, so it's usually safe there. What's likely different in your repro is the interaction between rapid typing and virtual scrolling specifically, when you type fast, each keystroke changes query, which re-filters options, and the virtualizer has to recompute visible rows and remeasure, if a state update from that recompute is still in flight (batched into a render) when the very next keydown's flushSync fires, you get the same "flushSync called from inside a lifecycle method" collision, just triggered by scroll/filter recomputation racing your typing instead of the autoFocus timing.

I don't have a confirmed root cause tying the exact virtual-scroll code path to this, that would need someone to trace it inside the library, but given the precedent already in combobox.tsx, this reads like a real gap rather than something on your end. Worth filing with your repro (it's already minimal and clear), referencing the existing microTask wrap around openCombobox as the pattern that likely needs to extend to whatever's firing here. In the meantime, debouncing your own query state updates by even one animation frame should sidestep it, since it stops the filter/remeasure cycle from overlapping with the next keystroke's synchronous handling.