Split out of #456, which improved the message but deliberately left the notification plumbing alone.
What happens
Load a bundle larger than the row limit. validateRowsBasic (data-loader/utils/validation.ts) throws, the loader dispatches data-error, and getDataLoadFailureNotification (apps/web/src/explore/notifications.ts) builds the toast.
Since #456 the message itself is good — it names the limit, explains that rows are proteins x projections, and suggests splitting projections. But the toast's only action is still "Report this", a prefilled bug-report mailto.
So a user who hits an intended, documented, correctly-explained limit is invited to file a bug about it.
Why it was not fixed in #456
getDataLoadFailureNotification chooses its action by asking asFastaPrepError(detail) — i.e. by the error's class, not by a code. DataErrorEventDetail has no code channel at all: createDataErrorEventDetail(error, originalError) does not carry one. So suppressing the action for this one case needs:
- a widened
DataErrorEventDetail with an optional code
- something to populate it for validation failures (the validators currently throw bare
Errors)
- a code extractor in the notification builder
- a third arm in the action ternary, alongside the Colab link and the report action
- tests for each
That is a reasonable change but it is not a one-liner, and #456 was already large. Descoped deliberately rather than half-done.
Suggested shape
Give the loader validation errors a small typed error class carrying a code (DATASET_TOO_LARGE, TOO_MANY_COLUMNS, TOO_MANY_CELLS), thread it through createDataErrorEventDetail, and give the notification builder a table of codes that are user-actionable limits rather than faults. Those get no report action — and could carry a docs link to the FAQ entry instead, which now explains the proteins x projections counting rule.
Acceptance
A bundle over the row limit produces a toast that names the limit and offers no bug-report action; an unexpected loader failure still offers one. Both covered in apps/web/src/explore/notifications.test.ts.
Split out of #456, which improved the message but deliberately left the notification plumbing alone.
What happens
Load a bundle larger than the row limit.
validateRowsBasic(data-loader/utils/validation.ts) throws, the loader dispatchesdata-error, andgetDataLoadFailureNotification(apps/web/src/explore/notifications.ts) builds the toast.Since #456 the message itself is good — it names the limit, explains that rows are proteins x projections, and suggests splitting projections. But the toast's only action is still "Report this", a prefilled bug-report mailto.
So a user who hits an intended, documented, correctly-explained limit is invited to file a bug about it.
Why it was not fixed in #456
getDataLoadFailureNotificationchooses its action by askingasFastaPrepError(detail)— i.e. by the error's class, not by a code.DataErrorEventDetailhas no code channel at all:createDataErrorEventDetail(error, originalError)does not carry one. So suppressing the action for this one case needs:DataErrorEventDetailwith an optionalcodeErrors)That is a reasonable change but it is not a one-liner, and #456 was already large. Descoped deliberately rather than half-done.
Suggested shape
Give the loader validation errors a small typed error class carrying a
code(DATASET_TOO_LARGE,TOO_MANY_COLUMNS,TOO_MANY_CELLS), thread it throughcreateDataErrorEventDetail, and give the notification builder a table of codes that are user-actionable limits rather than faults. Those get no report action — and could carry a docs link to the FAQ entry instead, which now explains the proteins x projections counting rule.Acceptance
A bundle over the row limit produces a toast that names the limit and offers no bug-report action; an unexpected loader failure still offers one. Both covered in
apps/web/src/explore/notifications.test.ts.