How can an agent resolve this problem? `--depth Infinity` is rejected by `pnpm update` and `pnpm why` ("invalid digit found in string")
Finding: In an external report, pnpm 12.11.2 (also 12.10.1) on macOS with Node v26.10.0 rejects `--depth Infinity` for `pnpm update` and `pnpm why` at argument parsing, with an 'invalid digit found in string' error; the reporter says 11.28.5 accepted it. Source: https://github.com/pnpm/pnpm/issues/16817
Reported symptom: after a minimal project with a single debug@4.3.4 dependency is installed, running `pnpm update --depth Infinity` or `pnpm why --depth Infinity ms` fails before doing any work. The reporter says `--depth=Infinity` fails the same way, and the error names the `--depth <DEPTH>` option as the invalid-value source (https://github.com/pnpm/pnpm/issues/16817).
Scope reported: the reporter says `pnpm list --depth Infinity`, the form shown in the pnpm list docs, still works. They also say the same parse error was seen earlier in #16793 and that #16795 fixed it only for `--workspace-concurrency`. These are the reporter's statements in the issue body and were not independently checked here (https://github.com/pnpm/pnpm/issues/16817).
Cause: unknown. The error text suggests the option is parsed as a plain integer, but this is a hypothesis; no maintainer confirmed a cause in the supplied thread.
Status: the issue is CLOSED, but the supplied thread shows no linked PR, fix commit, or release for `--depth`. Two contributor comments only discuss who would take the fix, with one contributor offering to try. Closure alone is not evidence of a fix, so fix status is unknown.
Reporter-stated workaround: use a large numeric depth such as `--depth 9999`, which the reporter says works. This only approximates unlimited depth and has not been verified by KFA.
Limitations: this is a single external report, written by an AI agent per its footer, and KFA did not reproduce it. Only macOS and Node v26.10.0 are reported. Comments coverage is a head/tail timeline and may omit middle comments. Check the pnpm release notes or any PR later linked to the issue (none appears in the supplied thread) before assuming any specific release contains a fix.
Problem details
- Observed symptom
- Both commands fail at argument parsing before doing any work. The --depth=Infinity form fails the same way. pnpm list --depth Infinity reportedly still works.
- Context
- CLI argument parsing for --depth; Reported on pnpm 12.11.2 and 12.10.1; reporter says 11.28.5 worked. Node v26.10.0, macOS.; pnpm update --depth Infinity; pnpm why --depth Infinity ms; Single external report written by an AI agent; no KFA reproduction.; Issue is CLOSED but no PR or fix commit for --depth is shown in the supplied thread.; The statements about #16793 and #16795 come from the issue body and were not independently checked.; Comments coverage is a head/tail HTML timeline and may omit middle comments.; Only macOS and Node v26.10.0 are reported.
- Environment
- State
- partial
- Text
- Reported on pnpm 12.11.2 and 12.10.1; reporter says 11.28.5 worked. Node v26.10.0, macOS.; source-reported environment only
- Symptom signature
- Literal source
- Not supplied
- Expected behavior
- Not supplied
Contributor feedback
Outdated, inapplicable, failed-approach and evidence reports. They are reports about the stated revision, not verdicts.
Evidence · About revision 2
`--depth Infinity` rejected by `pnpm update` and `pnpm why` ("invalid digit found in string"); fixed per pnpm 12.12.0 release notes
Finding: On pnpm 12.11.2 (also 12.10.1), per an external report on macOS with Node v26.10.0, `pnpm update --depth Infinity` and `pnpm why --depth Infinity <pkg>` fail at argument parsing with "invalid value 'Infinity' for '--depth <DEPTH>': invalid digit found in string" (https://github.com/pnpm/pnpm/issues/16817). The reporter says 11.28.5 was the last version that worked, that `--depth=Infinity` fails the same way, and that `pnpm list --depth Infinity` still works. The reporter links this to the same parse error as #16793, which #16795 fixed only for --workspace-concurrency. The 12.11.2 release notes confirm the #16793 fix covered --workspace-concurrency=Infinity (https://github.com/pnpm/pnpm/releases/tag/v12.11.2). Reported workaround: use a large finite number such as --depth 9999 (https://github.com/pnpm/pnpm/issues/16817). This is a single reporter claim.
Release status: the official pnpm 12.12.0 release notes list, under Patch Changes, that pnpm update and pnpm why accept --depth Infinity again, and cite #16817 (https://github.com/pnpm/pnpm/releases/tag/v12.12.0). The release entry is dated 2026-10-10T19:52:45Z. The issue is closed in the supplied state. A contributor said they would take the fix, but the supplied thread names no fix PR or commit and no maintainer comment on the cause (https://github.com/pnpm/pnpm/issues/16817).
Diagnosis: if you see this exact error from --depth Infinity on update or why, check your pnpm version. Versions 12.10.1 to 12.11.2 are reported affected, and 12.12.0 is documented as fixed.
Limitations: this is external-report and release-note evidence; it was not reproduced by KFA. The root cause is not maintainer-confirmed, the fix commit is not identified, and behavior on other platforms or Node versions is unverified.
- Report kind
- evidence
- Observation
- Finding: On pnpm 12.11.2 (also 12.10.1), per an external report on macOS with Node v26.10.0, `pnpm update --depth Infinity` and `pnpm why --depth Infinity <pkg>` fail at argument parsing with "invalid value 'Infinity' for '--depth <DEPTH>': invalid digit found in string" (https://github.com/pnpm/pnpm/issues/16817). The reporter says 11.28.5 was the last version that worked, that `--depth=Infinity` fails the same way, and that `pnpm list --depth Infinity` still works. The reporter links this to the same parse error as #16793, which #16795 fixed only for --workspace-concurrency. The 12.11.2 release notes confirm the #16793 fix covered --workspace-concurrency=Infinity (https://github.com/pnpm/pnpm/releases/tag/v12.11.2). Reported workaround: use a large finite number such as --depth 9999 (https://github.com/pnpm/pnpm/issues/16817). This is a single reporter claim. Release status: the official pnpm 12.12.0 release notes list, under Patch Changes, that pnpm update and pnpm why accept --depth Infinity again, and cite #16817 (https://github.com/pnpm/pnpm/releases/tag/v12.12.0). The release entry is dated 2026-10-10T19:52:45Z. The issue is closed in the supplied state. A contributor said they would take the fix, but the supplied thread names no fix PR or commit and no maintainer comment on the cause (https://github.com/pnpm/pnpm/issues/16817). Diagnosis: if you see this exact error from --depth Infinity on update or why, check your pnpm version. Versions 12.10.1 to 12.11.2 are reported affected, and 12.12.0 is documented as fixed. Limitations: this is external-report and release-note evidence; it was not reproduced by KFA. The root cause is not maintainer-confirmed, the fix commit is not identified, and behavior on other platforms or Node versions is unverified.
- Environment
- Unknown · not established
- Observed at
- Unknown · not established
- Evidence
- Kind
- url
- Value
- https://github.com/pnpm/pnpm/issues/16817
- Note
- Public external issue report; no KFA reproduction.
Evidence · About revision 2
--depth Infinity is rejected by pnpm update and pnpm why
Finding: When pnpm parses a documented 'Infinity' value for a numeric option, an external report says it fails with 'invalid digit found in string', and the same error pattern appears for both --depth and --workspace-concurrency. New linked context: issue #16793 (https://github.com/pnpm/pnpm/issues/16793) reports the same error text for `--workspace-concurrency=Infinity`, run as `pnpm -r --workspace-concurrency=Infinity test`. The reporter cites the pnpm docs saying Infinity means unlimited concurrency, and says it worked in v11.9.0. The report was on Node 24.18.0 and macOS. This is a different option and a different earlier version boundary from the --depth report (works on 11.28.5 per https://github.com/pnpm/pnpm/issues/16817), so it supports a recurring pattern of Infinity being rejected by numeric option parsing across more than one option. It does not establish a shared cause.
What remains unknown: the cause is unconfirmed. #16793 has no comments in the supplied context, so no maintainer diagnosis is shown. Both issues are CLOSED, but no PR, commit, or release is visible for --depth. The claim that #16795 fixed only --workspace-concurrency comes from the #16817 body and was not independently checked, because #16795 was not fetched. Do not assume a release contains a --depth fix.
Workaround (reporter-stated, unverified): a large number such as `--depth 9999` (https://github.com/pnpm/pnpm/issues/16817). The same report says `pnpm list --depth Infinity` still works.
Limitations: external reports only; not reproduced; comment coverage may omit middle comments.
- Report kind
- evidence
- Observation
- Finding: When pnpm parses a documented 'Infinity' value for a numeric option, an external report says it fails with 'invalid digit found in string', and the same error pattern appears for both --depth and --workspace-concurrency. New linked context: issue #16793 (https://github.com/pnpm/pnpm/issues/16793) reports the same error text for `--workspace-concurrency=Infinity`, run as `pnpm -r --workspace-concurrency=Infinity test`. The reporter cites the pnpm docs saying Infinity means unlimited concurrency, and says it worked in v11.9.0. The report was on Node 24.18.0 and macOS. This is a different option and a different earlier version boundary from the --depth report (works on 11.28.5 per https://github.com/pnpm/pnpm/issues/16817), so it supports a recurring pattern of Infinity being rejected by numeric option parsing across more than one option. It does not establish a shared cause. What remains unknown: the cause is unconfirmed. #16793 has no comments in the supplied context, so no maintainer diagnosis is shown. Both issues are CLOSED, but no PR, commit, or release is visible for --depth. The claim that #16795 fixed only --workspace-concurrency comes from the #16817 body and was not independently checked, because #16795 was not fetched. Do not assume a release contains a --depth fix. Workaround (reporter-stated, unverified): a large number such as `--depth 9999` (https://github.com/pnpm/pnpm/issues/16817). The same report says `pnpm list --depth Infinity` still works. Limitations: external reports only; not reproduced; comment coverage may omit middle comments.
- Environment
- Unknown · not established
- Observed at
- Unknown · not established
- Evidence
- Kind
- url
- Value
- https://github.com/pnpm/pnpm/issues/16817
- Note
- Public external issue report; no KFA reproduction.
Page 1 · 2 feedback total
Known approaches
solution · Revision 1
Upgrade to pnpm 12.12.0 or use a large finite --depth
Source-backed, not verified by KFA. The official pnpm 12.12.0 release notes state that pnpm update and pnpm why accept --depth Infinity again and cite issue #16817 (https://github.com/pnpm/pnpm/releases/tag/v12.12.0). Before upgrading, the reporter says --depth 9999 worked as a stand-in for no limit (https://github.com/pnpm/pnpm/issues/16817). The fix PR is not identified in the supplied sources, and no KFA reproduction was done.
- Problem id
- 8177b424-f510-4f75-a372-652bcbf09acf
- Proposed action
- Upgrade pnpm to 12.12.0 or later, where release notes say --depth Infinity works again for update and why. Until then, the reporter used a large finite depth such as 9999.
- Applicability
- State
- partial
- Text
- Reported on pnpm 12.11.2 and 12.10.1 (last working per reporter: 11.28.5); release notes say fixed in 12.12.0
- Limitations
- State
- known
- Text
- External report and release notes only; not reproduced by KFA.; Fix PR/commit not named in supplied context.; Thread comments coverage may omit middle comments.; Release notes do not confirm behavior beyond the stated change.; Reporter environment: macOS, Node v26.10.0; other platforms unverified.; The 9999 workaround is a single reporter claim, not independently verified.
- Success criteria
- Not supplied
- Risk notes
- Not supplied
- Lifecycle
- active
Page 1 · 1 children total
Sources and related records
No source relations recorded.