Skip to content

fix(log): handle org/log-id shorthand to prevent ContextError #1222

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sentry wants to merge 1 commit into
base: main
Choose a base branch
from
+19 −1
Open

fix(log): handle org/log-id shorthand to prevent ContextError #1222

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 19 additions & 1 deletion src/commands/log/view.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,11 @@
import { formatLogDetails } from "../../lib/formatters/index.js";
import { filterFields } from "../../lib/formatters/json.js";
import { CommandOutput } from "../../lib/formatters/output.js";
import { ageInDaysFromUuidV7, validateHexId } from "../../lib/hex-id.js";
import {

Check warning on line 30 in src/commands/log/view.ts

View check run for this annotation

@sentry/warden / warden: find-bugs

`org/log-id` shorthand still throws ContextError after fix 

The new `parsePositionalArgs` guard extracts the log ID from the `org/log-id` shorthand but returns `targetArg: "${org}/"`. Downstream, `parseOrgProjectArg("${org}/")` maps that to `{ type: "org-all" }`, and `resolveTarget` explicitly rejects `org-all` by throwing `ContextError("Specific project", ...)`. So the shorthand does not actually work — the original `"Log ID is required"` error is merely swapped for `"Specific project is required"`. Unlike the `replay/view.ts` and `event/view.ts` patterns the comment claims to mirror, log lookups genuinely need a project (`getLogs(org, project, ...)`), and there is no cross-project/org-only resolution path for logs, so `org/log-id` remains unresolvable. If the intent is merely a clearer error message this is acceptable, but the code comment ("Mirrors the pattern in replay/view.ts and event/view.ts") indicates the shorthand was expected to succeed, which it does not.
ageInDaysFromUuidV7,
tryNormalizeHexId,
validateHexId,
} from "../../lib/hex-id.js";
import {
handleRecoveryResult,
recoverHexId,
Expand Down Expand Up @@ -101,6 +105,20 @@
if (args.length === 1) {
// Single arg — could be slash-separated org/project/logId or a plain ID
// (possibly containing newlines)

// Handle <org>/<log-id> shorthand — must check before parseSlashSeparatedArg
// because a single-slash arg is interpreted as org/project with a missing ID,
// causing a ContextError. Mirrors the pattern in replay/view.ts and event/view.ts.
const slashIdx = first.indexOf("/");
if (slashIdx !== -1 && first.indexOf("/", slashIdx + 1) === -1) {
const org = first.slice(0, slashIdx);
const logSegment = first.slice(slashIdx + 1);
const normalizedLogId = logSegment && tryNormalizeHexId(logSegment);
if (normalizedLogId) {
return { rawLogIds: [normalizedLogId], targetArg: `${org}/` };

Check warning on line 118 in src/commands/log/view.ts

View check run for this annotation

@sentry/warden / warden: find-bugs

[BQA-CPP] `org/log-id` shorthand still throws ContextError after fix (additional location) 

The new `parsePositionalArgs` guard extracts the log ID from the `org/log-id` shorthand but returns `targetArg: "${org}/"`. Downstream, `parseOrgProjectArg("${org}/")` maps that to `{ type: "org-all" }`, and `resolveTarget` explicitly rejects `org-all` by throwing `ContextError("Specific project", ...)`. So the shorthand does not actually work — the original `"Log ID is required"` error is merely swapped for `"Specific project is required"`. Unlike the `replay/view.ts` and `event/view.ts` patterns the comment claims to mirror, log lookups genuinely need a project (`getLogs(org, project, ...)`), and there is no cross-project/org-only resolution path for logs, so `org/log-id` remains unresolvable. If the intent is merely a clearer error message this is acceptable, but the code comment ("Mirrors the pattern in replay/view.ts and event/view.ts") indicates the shorthand was expected to succeed, which it does not.

@cursor cursor Bot Jul 10, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Org log shorthand hits project error

Medium Severity

Single-argument org/log-id shorthand now sets targetArg to `${org}/`, which parseOrgProjectArg treats as org-all. resolveTarget always rejects org-all for log view, so the command still fails for the exact input this PR targets—only the ContextError message changes from “Log ID” to “Specific project”.

Additional Locations (1)
Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit bac9428. Configure here.

}
Comment on lines +117 to +119

@sentry sentry Bot Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: The new org/log-id shorthand for log view incorrectly generates a target that resolveTarget rejects, as it requires a specific project and receives an org-all type.
Severity: HIGH

Suggested Fix

The resolveTarget function in log/view.ts should be updated to handle the org-all case generated by the new shorthand. Instead of throwing an error, it should attempt to resolve the project, possibly by using a function similar to resolveOrgOptionalProjectFromArg used in replay/view.ts or by implementing logic to auto-detect the project when only an organization is provided with a log ID.

Prompt for AI Agent 
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/commands/log/view.ts#L117-L119

Potential issue: The fix introduces a shorthand format `org/log-id` for the `log view`
command. When this shorthand is used, the code generates a `targetArg` like `org/`. This
is parsed into an `org-all` type, indicating an organization without a specific project.
However, the `resolveTarget` function for `log view` explicitly throws a `ContextError`
for `org-all` types because it requires both an organization and a project to function.
Consequently, using the new shorthand will cause the command to fail with a "Specific
project is required" error, making the new feature non-functional.

Did we get this right? 👍 / 👎 to inform future reviews.

}

const { id, targetArg } = parseSlashSeparatedArg(
first,
"Log ID",
Expand Down
Loading