Repository navigation
fix(cli): Keep CliError exit codes for argument parser failures - #1651
sentry-junior[bot] wants to merge 1 commit into
Conversation
Stricli wraps any exception thrown from a flag or positional `parse` function in ArgumentParseError and always exits with InvalidArgument (-4, seen as 252). A ValidationError from a parser such as `--period bogus` therefore exited 252 instead of the documented 21, and lost its CliError formatting. The @stricli/core patch now accepts an optional `determineArgumentErrorExitCode` application hook. The app uses it to return the wrapped CliError's own exit code; other scanner errors keep InvalidArgument. Parser CliErrors are also rendered through formatError, keeping Stricli's input and parameter prefix. This removes one blocker for moving target parsing into positional parsers. Refs #1564 Co-Authored-By: BYK <burak.kaya@sentry.io>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 85b8870. Configure here.
BYK
left a comment
There was a problem hiding this comment.
At this point I'd prefer reverting to argument parser error for everything and accepting that or trying to wrap the stricli error class with ours if possible without patching it
|
@BYK, I looked into fixing this without patching Stricli. I haven't pushed anything yet. Stricli maps every scanner error to
Neither one is clearly better than keeping the patch, so I lean toward your first option: keep exit 252 for scanner-phase errors, document it, and close this PR. One question first: by "reverting to argument parser error for everything", do you also mean undoing #1594's lazy positionals, so that positional parse errors go back to 252 too? Or only leaving flags as they are on |

Refs #1564.
When a flag or positional
parsefunction throws, Stricli wraps the error inArgumentParseErrorand always exits withExitCode.InvalidArgument(-4, which the shell sees as 252). So aValidationErrorfrom one of our flag parsers loses its exit code. For example,sentry issue list --period bogusandsentry log list --sort sidewaysexit 252, but the exit code docs say a bad flag value exits 21. #1594 avoided this for target positionals by parsing them lazily insidefunc. Flag parsers still run in Stricli's scanner.Changes:
@stricli/corepatch adds an optionaldetermineArgumentErrorExitCodeapplication hook. Stricli calls it for each scanner error, and the first number it returns becomes the exit code. If the hook is unset or returnsundefined, Stricli exits withInvalidArgumentas before. The hook has aPATCH(getsentry/cli)marker, andcheck:patchesnow checks that it is present in both bundles.app.tsreturns the wrappedCliError'sexitCodefrom that hook. It also formats these errors withformatError, which handlesformat()and credential redaction. TheFailed to parse "<input>" for <param>:prefix stays the same.Errors that are not
CliErrors keep exit code 252. This includes Stricli's ownnumberParser(--limit abc), unknown flags, and missing positionals. Parse-phase errors still don't go throughreportCliErroror the--jsonerror output. Both are unchanged here.via BYK.
--
View Junior Session in Sentry