bug: `event view` silently produces no output when given org/project/event-id as single arg

[BYK]

Description

sentry event view silently produces zero output and exits with code 0 when given a single slash-separated argument like sentry/cli/abc123def. The user likely intended sentry event view sentry/cli abc123def (space-separated), but there's no error, no output, and no hint about the correct format.

Steps to Reproduce

sentry event view sentry/cli/abc123def456
echo $?   # prints 0

Actual behavior:

• stdout: empty
• stderr: empty
• exit code: 0

Expected behavior:

• Should exit with code 1 and print an error message like:

  Error: Invalid event ID "sentry/cli/abc123def456" (contains "/")
    Usage: sentry event view <org>/<project> <event-id>
  

Root Cause

The bug is in src/commands/event/view.ts:85-128 (parsePositionalArgs):

1. sentry event view sentry/cli/abc123def provides a single positional arg: "sentry/cli/abc123def"
2. parsePositionalArgs sees args.length === 1 (line 115) and returns { eventId: "sentry/cli/abc123def", targetArg: undefined }
3. The entire string becomes the "event ID", and targetArg is undefined
4. parseOrgProjectArg(undefined) returns AutoDetect (line 172-174 of arg-parsing.ts)
5. Auto-detection resolves an org/project from DSN or config defaults
6. getEvent(org, project, "sentry/cli/abc123def") is called with the full string as the event ID
7. The API returns a 404 or empty response, but the error is swallowed — the command exits cleanly

The lack of any output or error makes this particularly confusing for users.

Proposed Fix

Validate the event ID format in parsePositionalArgs before returning. Event IDs are 32-character hex strings — a value containing / is almost certainly a misformatted argument:

// After determining eventId (before the return statements):
if (eventId.includes("/")) {
  throw new ContextError(
    "Event ID (got a slash — did you mean two separate arguments?)",
    USAGE_HINT
  );
}

Additionally, the getEvent API call path should be investigated to understand why the 404 is being swallowed instead of propagating as an ApiError.

Files

• src/commands/event/view.ts:85-128 — parsePositionalArgs function
• src/commands/event/view.ts:177-269 — viewCommand.func (the command handler)
• src/lib/arg-parsing.ts:171-220 — parseOrgProjectArg function