assign-ports: warn on malformed explicit port env vars (follow-up to #242)#19
assign-ports: warn on malformed explicit port env vars (follow-up to #242)#19justin808 wants to merge 5 commits into
Conversation
readEnvOverride silently returned null when SHAKAPERF_CONTROL_PORT / SHAKAPERF_EXPERIMENT_PORT were set to a non-integer or other invalid value, so a typo was swallowed with no feedback while readBasePortOverride warns on the same class of input. Flagged by the code review on #242 as a pre-existing debuggability inconsistency. Extract parseExplicitPort: present + valid positive integer returns the port; absent/blank returns null silently; present-but-invalid warns and returns null, matching readBasePortOverride. Both vars must still be valid to pin the pair. Tightening to /^\d+$/ also drops the old hex/scientific Number() coercions (e.g. "0x1F"), which were never intended as ports. Tests: a present-but-invalid value warns and falls through; blank/absent vars stay silent. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…citPort Address the #245 review: - parseExplicitPort only checked the lower bound, so SHAKAPERF_CONTROL_PORT =99999 passed and returned an out-of-range port that docker would later fail to bind with no diagnostic. Reject > MAX_PORT, matching the ceiling readBasePortOverride enforces. - Add the privileged-range (<= PRIVILEGED_PORT_MAX) advisory so the explicit path warns like the base-port path, making the "matches readBasePortOverride" JSDoc accurate rather than aspirational. Tests: out-of-range explicit port warns and falls through; a privileged explicit pair warns but is still used. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Address the two non-blocking notes from the #245 review: - parseExplicitPort computed Number(stripped) three times; compute once. - readEnvOverride now warns when one explicit port var is set (or one side is invalid) but the pair doesn't resolve, so the whole override being dropped isn't masked by a per-var warning on just the bad half. Test: a lone SHAKAPERF_CONTROL_PORT warns and falls through. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis PR tightens explicit port environment parsing for automatic port assignment. The main changes are:
Confidence Score: 5/5The changed flow looks mergeable after a small cleanup to its diagnostics.
packages/shaka-shared/src/assign-ports.ts Important Files Changed
Reviews (1): Last reviewed commit: "assign-ports: warn on partial explicit o..." | Re-trigger Greptile |
ReviewSmall, well-scoped fix — extracting Correctness
Tests: good coverage — invalid integer, out-of-range, privileged-but-valid, only-one-var-set, and blank/absent-is-silent are all exercised, mirroring the existing Nit: left one inline comment — the new Security/perf: no concerns — this only affects local env-var parsing and console warnings, no new I/O or execution surface. Overall: looks correct and safe to merge; only the doc-comment nit above is worth a look. |
Review summaryFocused, well-scoped change: extracting One real gap (left as an inline comment): the de-duplication added in the latest commit ("avoid duplicate explicit-port warnings") only suppresses the generic "must be set to valid ports" message when both vars are non-blank. When exactly one var is set and that value is itself malformed (e.g. No security or performance concerns — this is pure env-var parsing with no external input trust boundary crossed, and the added regex/branching is negligible cost, only run once at process startup. |
ReviewTraced through One very minor, non-blocking observation: when one explicit var is valid-but-privileged (e.g. Tests are thorough (covers the malformed/out-of-range/privileged/partial-pair/blank matrix) and the new Nice, focused follow-up — LGTM. |
|
Ready to merge at HEAD Type: Checks:
Review threads:
Manual QA:
Adversarial review:
Docs-only skip: N/A. |
Follow-up to shakacode/shakaperf-old#242 review
The shakacode/shakaperf-old#242 review noted a pre-existing inconsistency in
assign-ports.ts:readBasePortOverride(SHAKAPERF_BASE_PORT/CONDUCTOR_PORT) warns on a non-integer, out-of-range, or privileged value.readEnvOverride(SHAKAPERF_CONTROL_PORT/SHAKAPERF_EXPERIMENT_PORT) silently returnednullfor non-integer/empty values — so a typo likeSHAKAPERF_CONTROL_PORT=40x0was swallowed with no feedback, and the run quietly fell through to the base-port/sticky path.Change
Extract
parseExplicitPort(env, varName):null, silently (the common case)console.warn(...)+null, mirroringreadBasePortOverrideBoth vars must still be valid to pin the explicit pair.
Tightening the check to
/^\d+$/also drops the oldNumber()coercions for hex/scientific notation (e.g."0x1F"→31), which were never intended as port specs.Tests
Local:
shaka-shared50/50 pass,tsc --noEmitclean.Migrated from shakacode/shakaperf-old#245 (original branch
jg/env-port-override-warnings). Cross-references above point to the original repo.