---
title: Guard the column-param select filter against a scalar param value
type: task
status: completed
description: >-
  ColumnParamSelectFilter calls selected_param_values?.forEach, and optional chaining guards only
  null and undefined, so a param whose persisted value is a scalar throws TypeError and blanks the
  data-view parameters editor. The fix is in the external mistakia/react-table dependency plus a pin
  bump here. Signal 125943.
base_uri: user:task/league/guard-column-param-select-filter-against-scalar-param-value.md
created_at: '2026-08-17T18:56:43.550Z'
entity_id: 4bcc0e54-2427-461c-8776-53f4215ac330
finished_at: '2026-08-20T01:15:12.328Z'
observations:
  - ████████████████████████████████████████████████
  - ████████████████████████████████████████████████
  - ████████████████████████████████████████████████
owner_identity_uri: █████████████████████████
priority: Medium
public_read: true
tags:
  - user:tag/league-xo-football.md
updated_at: '2026-08-20T01:15:12.328Z'
visibility_analyzed_at: '2026-11-05T23:49:34.582Z'
---

## Problem

`update_dynamic_values` in `node_modules/react-table/src/column-param-select-filter/column-param-select-filter.js:194-202` does:

```js
selected_param_values?.forEach((value) => { ... })
```

Optional chaining guards `null` and `undefined` only. A value that is present and not an array — a scalar string or number — reaches `.forEach` and throws `TypeError: e?.forEach is not a function`, inside a `useEffect`, which takes the whole parameters editor down rather than degrading one control.

`selected_param_values` is whatever the record holds: `parameters-editor-item.js:43-45` sets it from `record.get_value(param_name)` when every selected record agrees. Several param definitions are `single: true` with a scalar `default_value` — `scoring_format_id` in `app/core/data-views-fields/scoring-format-logs-table-fields.js` defaults to `DEFAULT_SCORING_FORMAT_ID`, a string — so a scalar is a shape this component can be handed.

The sibling controls already coerce rather than optional-chain: `column-param-nfl-week-selector.js:57,62` both read `selected_param_values || []`.

## Why this is not fixed in the league repo

`react-table` is an external git dependency pinned by commit — `package.json:180` reads `mistakia/react-table#a0828ecd47dc5805685a222d3ea442bb69b12826`. Editing `node_modules` is not durable. There is a local checkout at `user:repository/active/react-table`.

## Plan

- Decide whether a scalar is a legitimate persisted shape for a `single: true` param, or whether `sanitize_value` (`parameters-editor-item.js:14-21`) should be normalizing it on the write path. Fix the shape at its source if it is the latter; the coercion below is right either way, since a saved view can already hold a scalar.
- In `repository/active/react-table`, coerce before iterating in `update_dynamic_values`, matching the `|| []` form the nfl-week selector uses. Check the other reads of `selected_param_values` in the same file (`create_static_values`, `create_preset_values`, `create_dynamic_values`) for the same assumption rather than fixing the one line the stack named.
- Add a test in that repo driving the component with a scalar param value, proven red before the fix.
- Bump the `react-table` pin in `package.json` and `yarn.lock`.
- Deploy is SPA-side, so it needs `yarn build && yarn deploy:dist && yarn deploy:sourcemaps` — a backend deploy ships nothing to the browser.

## Verification

Reproduce first: the signal carries no `request_url` and no league/team context, so the failing view is unknown. Find a saved view or a default param whose stored value is a scalar and open its parameters editor; a repro is what makes the red test honest.

## Not the SQL drift

Signal 125943 fired at 18:36:23 UTC, ten minutes after the 18:23 deploy and pm2 reload restored `/api/players` and `/api/schedule`, from a different user, IP and browser than the reporters of the schema-drift 500s. The mechanism involves no database. It is not downstream of those 500s.