Skip to content

fix region refresh on percentile/timeframe update - #75

Merged
mda590 merged 1 commit into
mda590:mainfrom
agnoski:fix/region-refresh
Sep 11, 2026
Merged

mda590 merged 1 commit into
mda590:mainfrom
agnoski:fix/region-refresh

Conversation

@agnoski

@agnoski agnoski commented Apr 3, 2026

Copy link
Copy Markdown
Contributor

fix: sync region selection when percentile or timeframe updates

Summary

When the user changes percentile or timeframe, the app refetches latency data via updateData and replaces data. The available region keys come from Object.keys(data.data).

Previously, the useEffect that runs on [data] tried to merge newly appearing regions into selectedRegions. It did not reliably align the selection with the current payload when the set of regions changed in other ways, which led to a poor “refresh” experience after filter/timeframe updates.

This change replaces that merge logic with a simple intersection: keep only the previously selected regions that still exist in the latest data.data.

Behavior note

  • Removed: automatically adding newly introduced region keys to the selection whenever the API returns more regions than before (the assumption is that addition of a new region should be a pretty rare use-case, reinforced by the fact that data is updated every 6h).
  • Gained: selections never reference regions that are absent from the current response, so the matrix and region filter stay consistent after percentile/timeframe (or any data) updates.

How to verify (manual)

  1. Open the latency matrix with a dataset that lists regions.
  2. Narrow the region selection in the filter panel.
  3. Change percentile or timeframe and confirm selected regions only include regions present in the new response (no stale labels / empty rows from old keys).
  4. Optionally: load a response with additional regions vs. the previous one and confirm new regions are not auto-selected unless the user selects them (if product expects auto-select for new regions, that would be a follow-up).

@mda590
mda590 merged commit f7e2c60 into mda590:main Sep 11, 2026
mda590 added a commit that referenced this pull request Sep 11, 2026
#95 bumped next 15.5.25 -> 16.3.4 as a lockfile/version change only, so the
repo is on Next 16 without the breaking-change migration the upgrade guide
calls for. `npm run build` happens to still work (16 no longer runs lint as
part of the build), but `npm run lint` is broken on main today:

    > next lint
    Invalid project directory provided, no such directory: .../lint

because `next lint` was removed in 16 and `next` now reads "lint" as a
directory argument. This applies the rest of the migration.

- lint script calls eslint directly, and eslint.config.mjs imports
  eslint-config-next as flat config instead of going through the
  @eslint/eslintrc FlatCompat shim, which is dropped as a direct
  devDependency. The .next/next-env ignores that `next lint` applied
  implicitly are now declared.
- eslint-config-next 15.5.12 -> 16.3.4, which was left behind by #95 and no
  longer matches the installed next.
- react/react-dom 19.0 -> 19.3 and matching @types/*, per the upgrade guide.
- tsconfig: `jsx` must be "react-jsx" in 16 and .next/dev/types belongs in
  include (dev and build now use separate output directories). Next was
  rewriting both on every build, leaving the tree dirty; it no longer does.
- Turbopack is the default for dev and build in 16, so the explicit
  --turbopack flag is gone. There is no custom webpack config, so no
  --webpack opt-out is needed.
- LatencyMatrix: the effect added in #75 is now a render-phase adjustment.
  Next 16's lint config enables react-hooks/set-state-in-effect, which flags
  setState in an effect body as a cascading render. #75's semantics are kept
  exactly, including its data?.data guard: regions absent from the newly
  fetched payload are dropped from the selection, and nothing is auto-added.

The lockfile was regenerated with npm 11 so that sharp's per-platform `libc`
fields survive; npm 10 silently strips them, which would break musl/glibc
binary selection.

Verified: build, lint and tsc --noEmit all clean; `next start` serves /,
/visualization, /api/latencies, /region-status and /about; and in a browser
against the production build, deselecting three regions and then changing
both percentile and timeframe holds the selection at 32/35 with the
deselected rows absent - matching production's behavior after #75.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JgBXidouB5LfaxhmPgtUta
mda590 added a commit that referenced this pull request Sep 11, 2026
#95 bumped next 15.5.25 -> 16.3.4 as a lockfile/version change only, so the
repo is on Next 16 without the breaking-change migration the upgrade guide
calls for. `npm run build` happens to still work (16 no longer runs lint as
part of the build), but `npm run lint` is broken on main today:

    > next lint
    Invalid project directory provided, no such directory: .../lint

because `next lint` was removed in 16 and `next` now reads "lint" as a
directory argument. This applies the rest of the migration.

- lint script calls eslint directly, and eslint.config.mjs imports
  eslint-config-next as flat config instead of going through the
  @eslint/eslintrc FlatCompat shim, which is dropped as a direct
  devDependency. The .next/next-env ignores that `next lint` applied
  implicitly are now declared.
- eslint-config-next 15.5.12 -> 16.3.4, which was left behind by #95 and no
  longer matches the installed next.
- react/react-dom 19.0 -> 19.3 and matching @types/*, per the upgrade guide.
- tsconfig: `jsx` must be "react-jsx" in 16 and .next/dev/types belongs in
  include (dev and build now use separate output directories). Next was
  rewriting both on every build, leaving the tree dirty; it no longer does.
- Turbopack is the default for dev and build in 16, so the explicit
  --turbopack flag is gone. There is no custom webpack config, so no
  --webpack opt-out is needed.
- LatencyMatrix: the effect added in #75 is now a render-phase adjustment.
  Next 16's lint config enables react-hooks/set-state-in-effect, which flags
  setState in an effect body as a cascading render. #75's semantics are kept
  exactly, including its data?.data guard: regions absent from the newly
  fetched payload are dropped from the selection, and nothing is auto-added.

The lockfile was regenerated with npm 11 so that sharp's per-platform `libc`
fields survive; npm 10 silently strips them, which would break musl/glibc
binary selection.

Verified: build, lint and tsc --noEmit all clean; `next start` serves /,
/visualization, /api/latencies, /region-status and /about; and in a browser
against the production build, deselecting three regions and then changing
both percentile and timeframe holds the selection at 32/35 with the
deselected rows absent - matching production's behavior after #75.


Claude-Session: https://claude.ai/code/session_01JgBXidouB5LfaxhmPgtUta

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants