log view never finds any log ID — always fails

Start with packages/cli/src/lib/api/logs.ts and inspect getLogsBatch(), then follow how view.ts handles its empty result. Compare the current search request with the dedicated GET /projects/{org}/{project}/trace-items/{item_id}/ endpoint and its trace_id requirement. Done means log view can retrieve an ID freshly returned by log list instead of always reporting it as missing.

What happened

sentry log view <id> does not work, period. Every invocation, for every log ID (even one just printed by sentry log list moments earlier, in any project, in any org) fails with:

Error: Log '<id>' not found in sentry/sentry.

This isn't intermittent, isn't a stale-ID issue, and isn't fixed by waiting for propagation — it reproduces 100% of the time, immediately, for freshly-listed IDs.

Root cause

log view's only lookup mechanism, getLogsBatch() (packages/cli/src/lib/api/logs.ts), fetches a log by filtering the /organizations/{org}/events/?dataset=logs search endpoint on sentry.item_id:[<id>]. Verified directly against the raw API (bypassing the CLI): this filter never matches anything, in bracket or non-bracket form, with or without project scoping. sentry.item_id (and its public search alias id) is not a filterable/searchable column on this dataset's search endpoint at all in Sentry's backend (getsentry/sentry) — individual log items are only retrievable through a separate dedicated endpoint (GET /projects/{org}/{project}/trace-items/{item_id}/), which additionally requires a trace_id parameter that log view never supplies.

Because the search-filter lookup always returns zero rows, view.ts immediately throws "not found" and exits — the command cannot ever succeed as currently implemented, for any log ID, in any project or org.

Why this is confusing in practice

The error message ("Make sure the log ID is correct and was sent within the last 90 days") strongly implies a user input or retention problem. In reality the ID is always correct — copy-pasting an ID straight out of log list --json's own sentry.item_id field, seconds after listing it, still fails. There is nothing a user can do differently to make log view succeed today; the command's core retrieval mechanism does not function.

via lorenzo.

--

View Junior Session [Sentry]