TeamSearchField: filterSelectedOptions filters MUI's internal value, not the actual selection

[simihablo]

Summary

TeamSearchField keeps its real selection in parent state (teamsData) while leaving the MUI Autocomplete uncontrolled, and then relies on the Autocomplete's internal value for filterSelectedOptions. The two disagree, so the filtering is partial and does not survive a refetch.

Not a regression - it is the shape the component is left in after #1780 removed a value={inputValue} prop that bound a string to an object-valued Autocomplete. That prop was a type error masked by a file-level @ts-nocheck; removing the suppression forced it out and switched the component from (broken) controlled to uncontrolled, which is what made filterSelectedOptions start working at all. Keeping the now-live filter was a deliberate call - it restores what the author evidently intended and the UX is better. This issue is about finishing the job properly.

The mismatch

Three facts that do not compose:

1. The Autocomplete is single-select and uncontrolled. There is no multiple and no value. MUI's internal value is therefore the last selected option, not the selection set.
2. The real selection set lives in the parent, as teamsData, appended by handleAdd and rendered as Chips outside the Autocomplete.
3. filterSelectedOptions filters against fact 1, not fact 2. So at most one team - whichever was picked most recently - is hidden from the dropdown. Every other already-selected team stays listed.

On top of that, isOptionEqualToValue={(option, value) => option === value} is reference equality, and options is replaced wholesale on every fetchSuggestions(...) call (onInputChange, and the useEffect on mount / orgID change). After any refetch the retained value is no longer reference-equal to the new option objects, so even that single team reappears.

Net: the filter applies to one team, sometimes, until the next keystroke. What actually prevents a duplicate selection is the explicit guard in handleAdd, which sets the "Team Already Selected" error.

Why fix it

The component currently works by accident on two levels - correctness is carried by the handleAdd duplicate guard, while the visible filtering is incidental. Anyone who later needs to control the field programmatically (clear it after a successful invite, preselect teams when editing) will reach for value and land straight back on the bug that @ts-nocheck was hiding.

Suggested resolution

Either of these, not both:

• Derive the filter from the real selection. Drop filterSelectedOptions and filter options against teamsData directly, so every selected team is hidden, deterministically, regardless of refetches. Smallest change, keeps the component uncontrolled.
• Make it properly controlled. Give the Autocomplete a correctly-typed object value (or multiple with value={teamsData}), which makes filterSelectedOptions mean what it says and makes programmatic control possible.

In either case replace the reference comparator with an id comparison - (option, value) => option.id === value.id - since options identities are not stable across fetches.

Worth checking InviteUserModal's sibling pickers for the same pattern while in here.

[simihablo]

Correction: the filter is inert, not partial

The description above is wrong on a material point and I am correcting it rather than editing it away, so the record shows what was believed when.

I wrote that filterSelectedOptions filters against MUI's internal value and so hides "at most one team - whichever was picked most recently", reappearing after a refetch. That overstates it. It never hides anything at all.

Traced through the installed @mui/material@9.0.1 rather than reasoned about:

• filterSelectedOptions is applied in useAutocomplete.js:217-224, via isOptionSelected → selectedValues.some(v => isOptionEqualToValue(option, v)).
• This component passes reference equality: isOptionEqualToValue={(option, value) => option === value}.
• Selecting an option sets the input text to getOptionLabel(option), which is '' here. That fires onInputChange with reason 'reset' → handleInputChange → fetchSuggestions → a fresh options array of new objects.

So by the time the popup re-renders, the retained value is not reference-equal to any element of options, and isOptionSelected is false for every option. The filter is dead code in every state, not merely unreliable.

What this changes about the issue

The two suggested resolutions still stand and are still the right shape. What changes is the framing:

• This is not a behaviour regression to be preserved or reverted - there is no behaviour to preserve. Nothing in the UI changes today whether filterSelectedOptions is present or absent.
• Whoever picks this up is therefore implementing the hide-already-selected behaviour for the first time, not repairing it. That is a deliberate UX addition and should be reviewed as one.
• The duplicate guard in handleAdd (the "Team Already Selected" error) is not a partial backstop as I implied - it is currently the only thing preventing a duplicate selection.

Also worth knowing for whoever takes this: #1780 removed the @ts-nocheck from this file and a value={inputValue} prop that bound a string to an object-valued Autocomplete. That is what surfaced this. It shipped with the filter left inert and deliberately made no behaviour change here, so this issue owns making it real.

Related: #1783 (CustomTooltip's fixed dark surface vs ambient-themed contents) came out of the same audit.

[simihablo]

Second correction: it is state-dependent, and my earlier two descriptions were both wrong

Three passes over this have now produced three different answers, so here is the reading with line references, against the installed @mui/material@9.1.1 rather than from memory. Corrections welcome — that is the point of putting it here instead of in a code comment.

The mechanism

useAutocomplete.js, resetInputValue:

const newInputValue = getInputValue(newValue, multiple, getOptionLabel, renderValue);
if (inputValue === newInputValue) {
  return;                 // <- early return, no onInputChange
}
setInputValueState(newInputValue);
if (onInputChange) { onInputChange(event, newInputValue, reason); }

This component sets getOptionLabel={() => ''}, so newInputValue is always ''. Whether the early return fires therefore depends entirely on what the user typed before picking:

Flow	inputValue at pick time	Early return?	fetchSuggestions re-runs?	options replaced?	Filter hides the picked team?
Pick straight off the initially-loaded list (no typing)	''	yes	no	no	yes — the retained object is still reference-equal to its element of options
Type to search, then pick (the normal flow)	the typed text	no	yes (onInputChange fires with reason 'reset', and handleInputChange has no reason guard)	yes, with new objects	no — reference equality can never match again

So the filter works only for a pick made with an empty input, and stops working the moment anyone searches — which is the field's primary purpose.

What each previous description got wrong

• This issue's original description ("filters MUI's internal value… hides at most one team, until the next refetch"): wrong mechanism. It is not that the hide decays; it either happens and persists, or never happens at all.
• My first correction ("inert in every state"): wrong, because it missed the resetInputValue early return. Sorry — that one was confidently stated.
• A later reading ("no refetch fires, so it works"): correct only for the no-typing path; it does not hold once inputValue is non-empty.

For whoever picks this up

The two suggested resolutions in the description still stand. What matters is:

• At the base commit before chore(deps): bump js-yaml from 4.2.0 to 4.3.1 #1780, the filter was inert in all states, because value={inputValue} bound a string to an object-valued Autocomplete, so the reference comparator never matched anything. chore(deps): bump js-yaml from 4.2.0 to 4.3.1 #1780 removed that (it was a type error masked by a file-level @ts-nocheck) without intending a behaviour change, which is how the no-typing path started working.
• handleAdd's duplicate guard — the "Team Already Selected" error — is what actually prevents a duplicate pick in every path.
• An id-based isOptionEqualToValue fixes the comparator but not the refetch: handleInputChange re-runs fetchSuggestions on the 'reset' that selection triggers, replacing options wholesale. Both need addressing together, which is why the description recommends either deriving the filter from teamsData or making the component properly controlled.

#1780 ships no behaviour change of its own here and deliberately leaves only a minimal call-site note pointing at this issue, precisely because three careful passes disagreed about the behaviour — call-site prose would likely be wrong a fourth time.