log list/view --fields breaks on typed custom attributes
Los mantenedores suelen responder en 1 día
@BYK ya está trabajando en esto.
Desde el 9/9/2026.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
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 inlog list --help/log view --help— today it's only discoverable viasentry api --help.
via lorenzo.
--
- Lenguaje dominante
- TypeScript
- Estrellas
- 938
- Forks
- 166
- Merge medio
- 1 d 5 h
- PR fusionados (30 d)
- 171
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de getsentry/toolkit
-
bug MCP
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
getsentry/toolkit#1621 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
bug MCP
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
getsentry/toolkit#1618 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Docs MCP tool failures omit isErrorPosiblemente ocupada @thomasjiangcy la tomó hace 1 día. Abiertobug MCP
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
getsentry/toolkit#1600 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
getsentry/toolkit#1471 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
getsentry/toolkit#1632 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de getsentry/toolkit
Issues similares
-
type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 79/100
Los mantenedores suelen responder en 1 día
-
0️⃣ phase/new
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 70/100
microsoft/playwright#43640 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100