Skip to content

fix(explore): handle single -F flag as array to prevent TypeError #1218

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sentry wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fix(explore): handle single -F flag as array to prevent TypeError #1218

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/commands/explore.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -713,7 +713,7 @@
const userSuppliedFields = flags.field && flags.field.length > 0;
let fieldList = [...defaultFieldsForDataset(dataset)];
if (userSuppliedFields) {
fieldList = flags.field;
fieldList = Array.isArray(flags.field) ? flags.field : [flags.field];

Check warning on line 716 in src/commands/explore.ts

View check run for this annotation

@sentry/warden / warden: find-bugs

Single `-F` flag still causes TypeError in `appendFieldHints` via `appendFlagHints` 

The fix normalizes `flags.field` into `fieldList` but leaves the raw `flags.field` string un-normalized. `appendFlagHints` is called with `hintFlags = { ...flags, dataset }`, so `hintFlags.field` remains the bare string, which is passed to `appendFieldHints`. There the string reaches `fields.filter(...)` (when `--metric` is active) or `fieldList.join(",")` (the common non-metric case) — both throw `TypeError` because strings lack those array methods, reproducing the same crash the PR set out to fix.

@sentry-warden sentry-warden Bot Jul 9, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Single -F flag still causes TypeError in appendFieldHints via appendFlagHints

The fix normalizes flags.field into fieldList but leaves the raw flags.field string un-normalized. appendFlagHints is called with hintFlags = { ...flags, dataset }, so hintFlags.field remains the bare string, which is passed to appendFieldHints. There the string reaches fields.filter(...) (when --metric is active) or fieldList.join(",") (the common non-metric case) — both throw TypeError because strings lack those array methods, reproducing the same crash the PR set out to fix.

Evidence
  • flags.field is typed string[] | undefined but the CLI parser emits a string for a single -F flag (the PR's root cause).
  • The fix at line 716 coerces flags.field into a local fieldList, but never mutates or re-binds flags.field itself.
  • hintFlags = { ...flags, dataset } (line ~803) spreads the original flags, so hintFlags.field stays the raw string.
  • Both prevHint/nextHint are evaluated eagerly as arguments to paginationHint, so appendFlagHints runs on every invocation regardless of pagination state.
  • In appendFieldHints, const fields = rawFields ?? [] keeps the string; non-metric path hits fieldList.join(",") and metric path hits fields.filter(...), both throwing on a string.

Identified by Warden find-bugs · PQ4-HKP

@sentry sentry Bot Jul 9, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: The appendFieldHints function crashes with a TypeError because it receives a string for flags.field when a single -F flag is used.
Severity: HIGH

Suggested Fix

Ensure that flags.field is always an array before it is used by the hint generation functions. Similar to how fieldList is created, the flags.field property on the hintFlags object should be normalized to an array if it is a string. This will prevent the TypeError when .filter() is called within appendFieldHints.

Prompt for AI Agent 
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/commands/explore.ts#L716

Potential issue: When a user provides a single `-F` flag to the `explore` command, the
CLI parser sets `flags.field` to a string. While the main query logic correctly handles
this by converting it to an array, the pagination hint generation logic does not. It
uses a shallow copy of the original `flags` object, passing the string value of
`flags.field` to the `appendFlagHints` function, and subsequently to `appendFieldHints`.
The `appendFieldHints` function expects an array and attempts to call `.filter()` on the
string, which results in a `TypeError` and causes the command to crash after a
successful query.

Did we get this right? 👍 / 👎 to inform future reviews.

@cursor cursor Bot Jul 9, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Incomplete field array coercion

High Severity

The single -F coercion only updates fieldList, while pagination hint building still passes the raw flags.field into appendFieldHints. With one -F, that value remains a string, so .join or .filter still throws after the query succeeds and the command never returns results.

Additional Locations (2)
Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit 487dba7. Configure here.

}
const timeRange = flags.period;
const environment = parseReplayEnvironmentFilter(flags.environment);
Expand Down
Loading