Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

log list/view --fields breaks on typed custom attributes

オープン
  • 何か問題がありますか？
#1,474 コメント 1 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@BYK がすでに取り組んでいます。

2026年9月9日 から。

評価

この issue はまだ評価されていません。

説明

What happened

sentry log list / log view --fields supports requesting log attributes beyond the small set of fixed schema columns (timestamp, message, severity, trace, etc.). Those fixed columns resolve by plain name, but Sentry's logs backend requires custom/dynamic attributes to be requested with a type-qualified selector, tags[<name>,<type>] (e.g. tags[shard_id,number]) — because the same attribute name can be ingested as a different type across different log calls, so the query engine needs to know which typed column to read. Verified directly against the API: field=shard_id (plain) returns "shard_id": null, while field=tags[shard_id,number] returns the real value.

The bug: --fields is parsed by parseFieldsList() (packages/cli/src/lib/formatters/json.ts), which unconditionally splits the whole flag value on every comma. tags[shard_id,number] has a comma inside the attribute name, so requesting it shreds one valid field into two garbage fragments — tags[shard_id and number] — before it ever reaches the API. There is no escaping mechanism, and --fields cannot be repeated (a second --fields flag errors with "Too many arguments for --fields"), so there is currently no way to request a typed custom attribute through log list/log view --fields at all.

Why this is confusing in practice

sentry log list org/project --fields shard_id,num_shards looks like a normal, well-formed request and returns valid JSON — just with null for every custom field, with no error and no hint that these are custom attributes requiring the tags[name,type] form. Switching to the documented type-qualified syntax then hits a second, different-looking wall: --fields 'tags[shard_id,number]' still returns null, but now split into two malformed keys ({"tags[shard_id": null, "number]": null}). That looks like the type-qualified syntax itself isn't supported by these commands, when actually the comma inside it is being torn apart by the flag parser before the request is even built.

Root cause

parseFieldsList() in packages/cli/src/lib/formatters/json.ts does an unconditional .split(",") on the raw --fields string, with no awareness of the tags[name,type] bracket syntax used for custom log/span attributes elsewhere in the CLI. (sentry api -F 'field=tags[shard_id,number]' works correctly, because api.ts's field parsing doesn't have this issue — it's specific to the shared --fields flag parser used by log, trace, and span commands.) Any --fields value containing a bracketed, comma-containing attribute name breaks before it reaches the log/trace/span API layer.

Proposed fixes

  • Make parseFieldsList() bracket-aware: only split on top-level commas, treating [...] spans as atomic (a small tokenizer, or a regex that ignores commas inside brackets).
  • Alternatively/additionally, support repeating --fields (currently rejected) so multi-value selection doesn't depend on the flag's own comma-splitting.
  • Document the tags[name,type] syntax directly in log list --help / log view --help — today it's only discoverable via sentry api --help.

via lorenzo.

--

View Junior Session [Sentry]

主要言語
TypeScript
スター
938
フォーク
166
平均マージ
1日 4時間
マージ済み PR（30日）
175

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

getsentry/toolkit のほかの issue

getsentry/toolkit の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。