aipiJuancho opened a new issue, #44530:
URL: https://github.com/apache/superset/issues/44530
### Bug description
On a dashboard with a **vertical** filter bar, after clicking **"Clear
all"**, re-selecting the *same value that was just cleared* in a native Select
filter does nothing: the option is not checked, the filter tag does not appear,
and the "Apply filters" button stays disabled. Selecting a *different* value
works, and after that the previously-blocked value can be selected again. A
page reload also fixes it (until the next Clear all).
This is a **regression**: the vertical bar forwards
`clearAllTriggers`/`onClearAllComplete` correctly in 6.0.0 (tag `6a1c30e`,
2025-12-04) but not in 6.1.0 (`c83fb2bb`) nor in current master. The props were
dropped during the FilterBar sections refactor that wrapped `<FilterControls>`
in a `useMemo` (between the 6.0.0 tag and late Jan 2026).
### How to reproduce the bug
1. Open any dashboard with a vertical filter bar and a native Select filter
(e.g. "Canal").
2. Select a value (e.g. "BANCOS") and click **Apply filters**.
3. Click **Clear all**. The filter UI clears correctly.
4. Open the filter dropdown and click the same value ("BANCOS") again.
#### Actual results
Nothing happens. The option stays unchecked and "Apply filters" remains
disabled. Selecting any *other* value first unblocks it.
#### Expected results
The value is selected and can be applied.
### Environment
- Superset version: 6.1.0 (docker image `apache/superset:6.1.0`); still
present on master as of 2026-09-22.
- Browser: Chrome (also reproduced via automated browser session).
### Root cause
Two chained defects:
**1. Wiring gap (the trigger).** `FilterBar.handleClearAll` sets
`clearAllTriggers[filterId] = true` and passes
`clearAllTriggers`/`onClearAllComplete` to both bar orientations
(`FilterBar/index.tsx`). `Horizontal.tsx` forwards them to `<FilterControls>`,
but **`Vertical.tsx` destructures them and never forwards them** — they are
also missing from the deps of the `filterControls` `useMemo`, so even adding
them to the JSX alone would not re-render `FilterControls`. The trigger dies in
the vertical bar.
**2. Stale local state + JSON.stringify guards (the silent no-op).**
`SelectFilterPlugin` keeps a local mirror of the dataMask in a
`useImmerReducer` whose reducer only applies an action when
`JSON.stringify(draft.x) !== JSON.stringify(action.x)`, and notifies the parent
via `useEffect(() => setDataMask(dataMask), [JSON.stringify(dataMask)])`.
Because the `clearAllTrigger` effect in the plugin never fires (defect 1), the
local state stays frozen at the last selection while the parent's `filterState`
prop is cleared (the UI looks empty). Re-selecting the same value produces an
action whose JSON is identical to the frozen local state → the reducer discards
it → the push effect never fires → the dashboard state is never updated.
Verified by inspecting the plugin's React fiber state in a live 6.1.0
session: after "Clear all" the prop `filterState` is `{}` within ~120ms but the
local reducer state still holds
`{"extraFormData":{"filters":[{"col":"canal","op":"IN","val":["BANCOS"]}]},...}`
and `props.clearAllTrigger` is never `true` at any point (+120ms…+4s).
Dispatching the clear action directly into that reducer hook (what the
`clearAllTrigger` effect would do) immediately restores the expected behavior —
re-selecting the same value works again.
### Suggested fix
Restore the forwarding in `Vertical.tsx` (and add both props to the
`useMemo` deps):
```diff
<FilterControls
dataMaskSelected={dataMaskSelected}
+ clearAllTriggers={clearAllTriggers}
+ onClearAllComplete={onClearAllComplete}
onFilterSelectionChange={onSelectionChange}
...
/>
}, [
canEdit,
+ clearAllTriggers,
+ onClearAllComplete,
dataMaskSelected,
...
]);
```
On master, `clearAllTriggers`/`onClearAllComplete` must also be re-added to
the component's prop destructuring (they are still declared in
`VerticalBarProps` and still passed by `FilterBar/index.tsx`; `Horizontal.tsx`
still forwards them, which shows the intent).
### Checklist
- [x] I checked the Superset logs for python stacktraces (none — this is a
frontend state bug).
- [x] I reproduced the issue with the latest released version (6.1.0; also
verified the gap still exists on master).
- [x] I checked the issue tracker for the same issue and found none (PR
#44069 is a related but different stale-filter-state fix, for cascading
filters).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
