Skip to content

log view never finds any log ID — always fails #1475

Closed
Closed
log view never finds any log ID — always fails#1475
Assignees
BYK
Labels
jaredTrigger the Jared agent to work on stuff

Description

@sentry-junior
sentry-junior
bot
opened on Sep 9, 2026

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]

Activity

  1. sentry-junior commented on Sep 9, 2026

    @sentry-junior
    sentry-juniorBot
    on Sep 9, 2026
    ContributorAuthor

    Why the test suite didn't catch this

    The e2e mock server (packages/cli/test/mocks/routes.ts) hand-implements a fake sentry.item_id: filter that always succeeds:

    // If query contains sentry.item_id filter, return detailed log
// Query format: "project:${proj} sentry.item_id:${id}" or
//               "project:${proj} sentry.item_id:[id1,id2,...]"
if (query?.includes("sentry.item_id:")) {
  ...
  if (ids.includes(TEST_LOG_ID)) {
    return { body: logDetailFixture };
  }
  return { body: { data: [], meta: { fields: {} } } };
}

    The mock was written to match what the CLI sends, not what Sentry's real backend actually supports — so the sentry log view e2e tests (test/e2e/log.test.ts, e.g. "fetches log with valid auth") pass by construction: they verify only that the CLI builds the query it was written to build, never that the query is valid against real search semantics.

  2. BYK
    added
    jaredTrigger the Jared agent to work on stuff
    on Sep 9, 2026
  3. BYK
    self-assigned this
    on Oct 12, 2026
  4. BYK
    transferred this issue fromgetsentry/clion Oct 12, 2026

  5. linear-code commented on Oct 12, 2026

    @linear-code
    linear-codeBot
    on Oct 12, 2026 – with Linear Code

    MCP-1068

  6. sentry-junior commented on Oct 16, 2026

    @sentry-junior
    sentry-juniorBot
    on Oct 16, 2026
    ContributorAuthor

    The root cause described above is wrong. sentry.item_id filtering works on the logs dataset:

    • Raw /organizations/{org}/events/?dataset=logs queries with sentry.item_id:<id>, sentry.item_id:[<id>], id:<id>, and id:[<id>] all return the matching row.
    • The backend resolves the internal name sentry.item_id to the public id column (SearchResolver._find_column_by_internal_name in src/sentry/search/eap/resolver.py). The Sentry UI's pinned-log lookup uses the same filter, id:[...] (usePinnedLogsQuery.tsx).

    Actual cause: cli@0.47.0 searches the whole 90-day retention window with NORMAL sampling. On high-volume projects, that query often comes back with meta.dataScanned: "partial" and leaves out the requested row, so log view says "not found". Whether it fails depends on whether the scan is partial, so it fails often but not every time.

    Fix: #1451 (merged Oct 8) uses the timestamp encoded in each UUIDv7 log ID to limit the search to five minutes either side of it. If the scan comes back partial with IDs still missing, it retries those IDs once with HIGHEST_ACCURACY. #1463 (log view with multiple fully-qualified paths) also landed after 0.47.0.

    Verification: I took 9 log IDs from sentry log list on a high-volume project, ranging from minutes to about 30 days old. cli@0.47.0 reported "not found" for 5 of them. Current main found all 9.

    Neither fix is in a published release yet; cli@0.47.0 predates both. They will be out with the next CLI release.

    The mock-server gap noted above still exists: the e2e mock never returns a partial scan. The partial-scan path is covered by the unit tests in packages/cli/test/lib/api/logs.test.ts added in #1451.

  7. sentry-junior
    closed this as completedon Oct 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

jaredTrigger the Jared agent to work on stuff

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions