Skip to content

fix: Preserve known CLI args when custom flags are present#5325

Open
realmeylisdev wants to merge 1 commit into
serverpod:mainfrom
realmeylisdev:fix/custom-cli-flags-ignored
Open

fix: Preserve known CLI args when custom flags are present#5325
realmeylisdev wants to merge 1 commit into
serverpod:mainfrom
realmeylisdev:fix/custom-cli-flags-ignored

Conversation

@realmeylisdev

Copy link
Copy Markdown
Contributor

Summary

Closes #2396

ArgParser.parse throws ArgParserException on any unrecognised flag or option. The catch block in CommandLineArgs was nulling all fields on any parse failure — so passing a custom flag like --myCustomFlag alongside --mode=production caused the server to silently start in development mode.

Root cause

dart bin/main.dart --mode=production --myCustomFlag
# ArgParser throws on --myCustomFlag
# catch block nulls _runMode, so runMode falls back to "development"

Fix

Added _filterKnownArgs — a static helper that walks the raw token list and strips any flag or option the ArgParser doesn't know about, based on parser.options (so it's always in sync with the registered args). The filtered list is then passed to parse().

  • Unknown flags (--myCustomFlag) → silently ignored ✓
  • Unknown options with values (--myCustomOption someValue) → silently ignored ✓
  • Known options with invalid values (--logging invalid) → still trigger the catch + fall back to defaults ✓
  • All existing behaviour for malformed args preserved ✓

Test plan

  • All 24 existing tests still pass
  • 5 new tests cover: custom flag after known option, before known option, custom option+value before known option, =-style syntax, and multiple known options mixed with multiple custom flags
  • 29/29 total tests passing

Closes serverpod#2396

ArgParser.parse throws on any unrecognised flag, which caused the
catch block to null all fields — so --mode=production was silently
discarded whenever a custom flag like --myCustomFlag was also passed.

_filterKnownArgs now strips unknown tokens from the args list before
handing it to the parser, so user-defined flags are ignored and all
registered Serverpod options are parsed correctly.

Known options with invalid values (e.g. --logging invalid) still
trigger the catch and fall back to defaults as before.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Serverpod flags are not parsed if a custom flag are used.

1 participant