projector: parseLimit still reinterprets non-decimal spellings — limit=1e2 / 0x10 / 5.0 / +5 are honoured instead of falling back to the default (#1547 residual)

projector: parseLimit still reinterprets non-decimal spellings — `limit=1e2`, `0x10`, `5.0`, `+5`, `5` are honoured as numbers instead of falling back to the default

Evidence (verified this run, main `9b689eb5`)

pm-stack/projector/src/server.ts:50-56 — the fix for #1547:

export function parseLimit(raw: string | null, defaultLimit: number, maxLimit: number): number {
  if (raw === null) return defaultLimit;
  const n = Number(raw);
  if (!Number.isInteger(n) || n < 1) return defaultLimit;
  return Math.min(n, maxLimit);
}

Its own doc comment (:42-49) says "Only a positive integer is honoured" and that negative/fractional/non-numeric values fall back to the endpoint default. But the check is on the Number()-coerced value, not the spelling, so any spelling Number() coerces to an integer passes:

Probe (laptop, ~/git/fleet/probe-2026-10-31-laneB-projector/, real parseLimit imported from the md5-matched server.ts of main 9b689eb5, defaults 200/1000):

raw	result	expected per the #1547 contract
`"1e3"`	1000	default 200 (scientific spelling)
`"1e2"`	100 (same mechanism)	default 200
`"0x10"`	16	default 200 (hex spelling)
`"5.0"`	5	default 200 (fractional spelling — `2.7` falls back, `5.0` does not)
`"+5"`	5	default 200
`" 5"`	5	default 200
`"5"`	5	5 (control, honoured)
`"2.7"`, `"abc"`	200	200 (controls, fall back)

Used by both read endpoints: /items (server.ts:139) and /comments (server.ts:148). The existing test matrix (pm-stack/projector/test/limit.test.ts) covers -1, 0, 2.7, abc, "", NaN, Infinity — none of the coercible spellings above.

Why it matters

This is the exact reinterpretation class the repo keeps removing site by site (#2789/#2791/#2743 for measurement parsers, #832 for world seeds, the digits-only rule in bin/proxy-port.mjs): a client that sends limit=0x10 or limit=1e2 gets a silently different page size than the API contract states, and 5.0 vs 2.7 behaving differently is an inconsistency inside the fix's own test matrix. The bound itself still holds (results are clamped), so this is correctness/contract drift, not an unbounded-read hole — priority/low.

Acceptance criteria

parseLimit honours only a plain decimal positive-integer spelling (digits only, e.g. /^[0-9]+$/ after the absent-parameter check); 1e2, 1e3, 0x10, 5.0, +5, leading/trailing-whitespace, and empty spellings fall back to the endpoint default.
Well-formed values behave exactly as today: honoured exactly, over-max clamped to the per-endpoint maximum, absent parameter keeps the default.
test/limit.test.ts gains the coercible-spelling matrix above for both endpoints' defaults/maxima; existing projector: read-API limit is never validated — ?limit=-1 returns the whole table and ?limit=2.7 500s the request #1547 tests pass unchanged.
No change to the endpoints, defaults (items 200/1000, comments 500/1000), or the store layer.

🤖 Agent note · filed

Agent: new-issue-creator (lane B, new-issue-creator-code-b)
Session / ID: new-issue-creator-code-b run 2026-10-31T06:50Z (America/Chicago scheduled run)
Found via: filed this run
Task: Triage the parseLimit non-decimal spelling reinterpretation (projector read API, projector: read-API limit is never validated — ?limit=-1 returns the whole table and ?limit=2.7 500s the request #1547 residual) and route the strict-spelling fix
Expectation: effort/xs — done looks like: only plain decimal spellings honoured, coercible spellings fall back to the endpoint default, limit.test.ts gains the spelling matrix
Links: probe on laptop ~/git/fleet/probe-2026-10-31-laneB-projector/ (real parseLimit, md5-matched main 9b689eb)

🤖 Agent note · done (triage)

Agent: queue worker (repo-worker-code), Lane A
Session / ID: queue task 4269, shift 2026-10-31 01:04 CDT
Found via: queue claim
Task: Triage projector: parseLimit still reinterprets non-decimal spellings — limit=1e2 / 0x10 / 5.0 / +5 are honoured instead of falling back to the default (#1547 residual) #2971 — projector parseLimit honours non-decimal limit spellings (projector: read-API limit is never validated — ?limit=-1 returns the whole table and ?limit=2.7 500s the request #1547 residual)
Verdict: CONFIRMED on current main (verified fresh via the GitHub API this run). pm-stack/projector/src/server.ts parseLimit (L50–56) is const n = Number(raw); if (!Number.isInteger(n) || n < 1) return defaultLimit; return Math.min(n, maxLimit) — so Number("1e2")=100, Number("0x10")=16, Number("5.0")=5, Number("+5")=5, and Number(" 5")=5 all pass the integer gate and are honoured/clamped instead of falling back to the default. Both call sites verified: /items (L139, default 200 / max 1000) and /comments (L148, default 500 / max 1000). test/limit.test.ts covers the projector: read-API limit is never validated — ?limit=-1 returns the whole table and ?limit=2.7 500s the request #1547 negative/fractional/non-numeric/zero cases but has no coercible-spelling cases.
Fix pinned: honour only /^[0-9]+$/ spellings (parse digits, ≥1, clamp to max as today); absent parameter still defaults; every other spelling falls back to the endpoint default. Fix packet requires the coercible-spelling matrix (1e2, 0x10, 5.0, +5, 5, 5 ) in test/limit.test.ts for both endpoints, existing projector: read-API limit is never validated — ?limit=-1 returns the whole table and ?limit=2.7 500s the request #1547 tests unchanged. No endpoint/default/store changes.
Routing: follow-up fix enqueued as queue task 4275 (small_fix, dedupe repo-health:v1:fix:developing-today/code:issue:2971). Issue stays open for the fix.
Expectation: triage done; fix is a separate queued task (effort/xs, low risk).
Links: issue projector: parseLimit still reinterprets non-decimal spellings — limit=1e2 / 0x10 / 5.0 / +5 are honoured instead of falling back to the default (#1547 residual) #2971

agent-note:v1
event: parked
task: 4275
pr: #3077
note: Parked 20m awaiting the Codex review just requested. No CI runs exist for pm-stack paths (check-runs API verified); laptop suite on PR head 132543d: 44 pass / 0 fail. Resume condition: Codex clean -> merge -> close.

🤖 Agent note · picked up

Agent: queue worker (repo-worker-code), lane C shift
Session / ID: queue task 4275 (resume)
Found via: queue claim
Task: Resume from targeted_tests_passed: Codex re-review of PR 3077 head 132543d completed clean (has_any_findings=false, receipt 2026-10-31T15:29Z), PR MERGEABLE/CLEAN, only check run is CodeRabbit neutral (no CI exists for pm-stack paths), laptop suite already green on this head (projector 44 pass, limit.test.ts 13/13). Merging.
Expectation: Merge PR 3077 → close projector: parseLimit still reinterprets non-decimal spellings — limit=1e2 / 0x10 / 5.0 / +5 are honoured instead of falling back to the default (#1547 residual) #2971 → complete task as fixed_merged.
Links: PR fix(projector): parseLimit honours only decimal-digit spellings (#2971) #3077

Merge pull request #3077 from developing-today/queue/4275-2971-projec…

🤖 Agent note · done

Agent: queue worker (repo-worker-code), lane C shift
Session / ID: queue task 4275
Found via: queue claim (resume)
Task: PR 3077 merged — merge commit 7946d8f. Codex review clean on head 132543d (no findings, all rounds dispositioned); no CI runs exist for pm-stack paths (only CodeRabbit neutral); laptop verification on the merged head: projector suite 44 pass / 0 fail, limit.test.ts 13/13. Issue closed by the merge. Task completed as fixed_merged.
Expectation: done — no follow-up.
Links: PR fix(projector): parseLimit honours only decimal-digit spellings (#2971) #3077

Navigation Menu

Repository navigation

projector: parseLimit still reinterprets non-decimal spellings — limit=1e2 / 0x10 / 5.0 / +5 are honoured instead of falling back to the default (#1547 residual) #2971

projector: parseLimit still reinterprets non-decimal spellings — `limit=1e2`, `0x10`, `5.0`, `+5`, `5` are honoured as numbers instead of falling back to the default

Evidence (verified this run, main `9b689eb5`)

Why it matters

Acceptance criteria

33 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

projector: parseLimit still reinterprets non-decimal spellings — limit=1e2 / 0x10 / 5.0 / +5 are honoured instead of falling back to the default (#1547 residual) #2971

Description

projector: parseLimit still reinterprets non-decimal spellings — limit=1e2, 0x10, 5.0, +5, 5 are honoured as numbers instead of falling back to the default

Evidence (verified this run, main 9b689eb5)

Why it matters

Acceptance criteria

Activity

dezren39 commented on Oct 31, 2026

dezren39 commented on Oct 31, 2026

33 remaining items

dezren39 commented on Oct 31, 2026

dezren39 commented on Oct 31, 2026

dezren39 commented on Oct 31, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

projector: parseLimit still reinterprets non-decimal spellings — `limit=1e2`, `0x10`, `5.0`, `+5`, `5` are honoured as numbers instead of falling back to the default

Evidence (verified this run, main `9b689eb5`)