Repository navigation
fix(explore): handle single -F flag as array to prevent TypeError - #1218
sentry[bot] wants to merge 3 commits into
Conversation
|
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 487dba7. Configure here.
Codecov Results 📊✅ Patch coverage is 100.00%. Project has 5496 uncovered lines. Coverage diff@@ Coverage Diff @@
## main #PR +/-##
==========================================
+ Coverage 81.74% 81.74% —%
==========================================
Files 428 428 —
Lines 30106 30106 —
Branches 19593 19585 -8
==========================================
+ Hits 24611 24610 -1
- Misses 5495 5496 +1
- Partials 2054 2056 +2Generated by Codecov Action |
The previous fix only coerced the local fieldList, leaving the raw flags.field string in hintFlags. A single -F flag still crashed with a TypeError in appendFieldHints (via appendFlagHints) after a successful query, because the pagination-hint path called .filter/.join on the string. Normalize once at the source via normalizeFields so fieldList, hintFlags, and contextKey all see an array. Adds a regression test. Fixes CLI-28C.
487dba7 to
28f1681
Compare
|
Good catch from Warden, Seer, and Bugbot — all three flagged the same real gap: the original fix only coerced the local Fixed by normalizing once at the source ( Also rebased onto |
Same variadic-flag bug class as -F: a single -e arrives as a bare string, so parseReplayEnvironmentFilter's [...values] spread split it into characters and the pagination-hint loops emitted -e "p" -e "r"... Add a shared normalizeVariadicFlag helper in replay-search, harden parseReplayEnvironmentFilter (fixes the query path for both explore and replay list), and use it in both hint builders. Consolidates the explore -F coercion onto the same helper. Reported by Seer on CLI-28C.
|
Closing as part of archiving getsentry/cli; the CLI now lives in getsentry/toolkit. Superseded by getsentry/toolkit#1607. Stricli always gives variadic flags to handlers as arrays, so only the library SDK can pass a scalar. That PR normalizes scalars at the SDK boundary for every command instead of patching |
…me (#1607) Two places where what the library SDK accepts doesn't match what commands actually get: - **Scalar values for variadic flags.** Stricli always passes variadic flags to a handler as arrays, but the SDK forwards the caller's flags as-is. An untyped caller passing `{ field: "title" }` to `explore` crashed with `e.find is not a function` ([CLI-28C](https://sentry.sentry.io/issues/7602736942/), [CLI-2B4](https://sentry.sentry.io/issues/7630797537/)). getsentry/cli#1648 fixed the generated types. `applyFlagDefaults` now also wraps scalar values in an array at runtime, so plain JS callers work. - **Streaming overloads.** The `AsyncIterable` overload for `log list --follow` and `dashboard view --refresh` didn't accept trailing positionals, so `sdk.log.list({ follow: "5" }, "org/project")` failed to type-check even though the runtime accepts it. This replaces three getsentry/cli PRs that patched `explore` directly. #1293's `parse: (v: string[]) => v` was wrong because Stricli calls `parse` once per value. #1218 and #1294 coerced the arrays inside `explore`. The variadic fix here is at the SDK boundary, which is the only path that can pass a scalar. Ported from getsentry/cli#1218, getsentry/cli#1293, getsentry/cli#1294, and the SDK part of getsentry/cli#1655. All are being closed with the repo archive. <!-- junior-request-attribution:start --> via **BYK**. <!-- junior-request-attribution:end --> <!-- junior-session-footer:start --> <!-- junior-conversation-id:local%3Aweb%3Ad9c5b0de1ecf3c7114be7025 --> -- [View Junior Session in Sentry](https://sentry.sentry.io/explore/conversations/local%3Aweb%3Ad9c5b0de1ecf3c7114be7025/?project=4510944073809921) <!-- junior-session-footer:end --> Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: BYK <burak.kaya@sentry.io>

This PR addresses CLI-28C, a TypeError occurring in the
explorecommand.Root Cause:
The
flags.fieldargument insrc/commands/explore.tsis defined asvariadic: true. However, when a user supplies only a single-Fflag, the CLI parser assigns a string toflags.fieldinstead of a single-element array. The command function then blindly assignsfieldList = flags.field, makingfieldLista string. Subsequent calls to.find()onfieldList(e.g., inresolveDatasetConfigorfindFirstAggregate) then fail withTypeError: e.find is not a functionbecause strings do not have a.find()method.Fix:
To resolve this,
flags.fieldis now explicitly coerced to an array before being assigned tofieldList. This ensures thatfieldListis always an array, regardless of whether one or multiple-Fflags were provided, thus preventing the TypeError.Fixes CLI-28C
Comment
@sentry <feedback>on this PR to have Autofix iterate on the changes.