---
title: Stop query-backed aliases drowning the stranded-saved-view alarm
type: task
status: draft
description: >-
  On the /u/ shared-link path selected_data_view.query_id is falsy, so the unresolved-column bugsnag
  suppression never fires and every ad-hoc alias reports on every render -- 240 reports in three
  hours, drowning the only alarm for a rename that stranded a saved view.
base_uri: user:task/league/data-views/stop-query-aliases-drowning-the-stranded-view-alarm.md
created_at: '2026-09-20T17:34:44.332Z'
entity_id: 3e1b721c-a0ed-4bcc-a37e-b07f4ee62a30
owner_identity_uri: █████████████████████████
public_read: true
relations:
  - relates [[█████████████████████-████████████████-███████-█████-██████-████████]]
tags:
  - user:tag/league-xo-football.md
  - user:tag/software-task.md
updated_at: '2026-09-20T17:34:53.888Z'
visibility_analyzed_at: '2026-11-05T23:49:01.846Z'
---

# Stop query-backed aliases drowning the stranded-saved-view alarm

## The defect

`get_players_percentiles` in `app/views/pages/data-views/index.js` reports an unresolved `column_id` to bugsnag, and suppresses that report for a query-backed view by testing `selected_data_view.query_id`. On the `/u/<hash>` shared-link path that field is FALSY, so the suppression never fires and every ad-hoc alias in the view reports on every render.

Measured on production 2026-09-20: 240 reports in roughly three hours, every one of them the four aliases of a single view (`series_success_rate_allowed`, `drive_td_rate_allowed`, `explosive_run_rate_allowed`, `explosive_pass_rate_allowed`), generated by two sessions merely LOOKING at that view. No other column id appears in the log at all.

## Why it matters more than the volume suggests

That branch is the only alarm for a rename that stranded a real user's saved view. It has incident history behind it -- the 2026-08-17 counting-stat conform blanked SEASON_PROJECTIONS for every user and this is what caught it. An alarm that fires hundreds of times for a benign cause is an alarm nobody reads, so the cost is not the log volume but the next stranded-view incident going unnoticed inside the noise.

The comment at that branch explicitly states the design intent: a query-backed view's aliases are absent from the registry BY CONSTRUCTION and would otherwise turn a real alarm into noise proportional to how many query-backed views get opened. That is exactly what is happening; the guard just does not work on the path that matters.

## Scope

- Establish why `selected_data_view.query_id` is falsy for a shared-link view when the page clearly knows the view is query-backed -- the query-backed notice renders correctly on the same page, so SOMETHING holds the fact. Find that and key the guard on it.
- Prefer a condition that cannot silently stop matching. Keying on the presence of query-backed descriptors, or on a view-level flag the notice already uses, both beat re-testing a field that is populated on some paths and not others.
- The suppression must stay NARROW: a registry column that fails to resolve must still report, on every path, including inside a query-backed view.

## Notes

Predates `percentile-shading-query-backed-views.md`; the first report is timestamped hours before that change existed. That change preserved the same guard clause and so neither caused nor fixed this.

Verify with a control rather than by reading the log after a fix: load the shared link, confirm zero new reports for the four aliases, then load a saved registry view with a deliberately unresolvable column id and confirm that one DOES report. A fix that silences both is a regression wearing the shape of a success.