sf check global-view fails immediately on org-information dataset (queryMore error) — EE org with all 4 required permissions

[DedicatedCPA]

Describe the bug

After installing @orgcheck/sfdx-plugin@8.0.5, every sf check subcommand (global-view, apex-classes, hardcoded-urls) errors out within seconds at the org-information dataset with a queryMore SOQL failure. The in-app VF page version of Org Check works fine on the same org with the same user.

Environment

• macOS Darwin 25.2.0, ARM64
• Node v22.13.1
• @salesforce/cli 2.133.4 (also reproduced on 2.125.2 — upgrading did not help)
• @orgcheck/sfdx-plugin 8.0.5 (latest)
• Org: Enterprise Edition, NamespacePrefix=null, ~1700 unmanaged ApexClass, ~2300 CustomField, 178 PermissionSetAssignments matching the plugin's filter. Not unusually large.

Required permissions verified TRUE for the running user

Confirmed via direct SOQL probe (per the fix path described in #714):

PermissionsModifyAllData       True
PermissionsAuthorApex          True
PermissionsApiEnabled          True
PermissionsInstallPackaging    True

Reproduction

sf plugins install @orgcheck/sfdx-plugin    # → installed v8.0.5 ✓
sf check global-view --target-org production --xlsx-file /tmp/x.xlsx --accept-the-terms
sf check apex-classes --target-org production --xlsx-file /tmp/x.xlsx --accept-the-terms
sf check hardcoded-urls --target-org production --accept-the-terms
sf check clear-all-cache --target-org production

All produce identical error within ~3 seconds:

Error (1): An error occurred while running the dataset
(message: There was an error while retrieving the data for this dataset
(either cache issue or dataset.run issue).
... at nt.<anonymous> (.../@orgcheck/api/dist/orgcheck.js:1:141809)

JSON output (--json flag) reveals the underlying cause chain:

recipe: 'org-information',
cause: Error: There was an error while running a SOQL query with the standard queryMore
       at Fa.<anonymous> (.../orgcheck.js:1:266887)

Eliminated as causes

Hypothesis	Tried	Result
Missing 4 required perms	Direct probe of UserPermissionAccess	All 4 = TRUE ✓ (matches #714/#715 fix path)
Stale plugin cache	sf check clear-all-cache then --invalidate-cache flag	Same error
Auth token expired	sf org refresh-token then retry	Same error
--accept-the-terms not set	Set on every call	Same error
Specific subcommand bug	All 3 sf check commands	Identical error
@salesforce/cli version	Upgraded 2.125.2 → 2.133.4	Same error
The org-information primary query is broken	Direct sf data query -q "SELECT Id, Name, IsSandbox, OrganizationType, TrialExpirationDate, NamespacePrefix FROM Organization LIMIT 1"	Returns the row cleanly — so the failing query is something else the dataset bundles, OR a CLI-vs-VF execution-path difference

What still works

The in-app VF page version of Org Check works fine on this org. The Excel export from OrgCheck_App_VFP is clean (we use it as our weekly source today). So the same engine + same Tooling API endpoints + same user identity succeed in-browser; only the CLI plugin path fails.

Asks

1. Could you point me at where the org-information dataset's full query list is composed in packages/orgcheck-api/? I'd like to localize whether a specific query is failing or whether it's a CLI execution wrapper bug.
2. Is there a verbose / trace log flag for the plugin that would expose the exact failing SOQL string before it's sent? SFDX_LOG_LEVEL=debug doesn't surface it.
3. Happy to file a PR if I can pinpoint the offending query/path.

Thanks for the project — the in-app version is a daily driver for us.

[VinceFINET]

list of queries performed by both application (they share the same library --> https://salesforcelabs.github.io/OrgCheck/queries/

normally the logs would be located at .sf
The logs filename look like this on my mac: sf-2026-05-07.log

[VinceFINET]

I see the target org is "production" in case of a production org the plugin should output the following error without a speicifc tag for produciton usage

So try to add "--accept-the-terms" in the command

if it works nice!
but i need to fix the error / message because in your case you didn't have any information.
sorry about that.

[DedicatedCPA]

Update — found the actual root cause in the logs (~/.sf/sf-2026-05-07.log). The bug is not queryMore. The user-facing error wraps a different underlying cause.

Confirming I did pass --accept-the-terms on every attempt yesterday. From the log (line 714):

"process.argv: [
  '/usr/local/bin/node',
  '/usr/local/bin/sf',
  'check',
  'apex-classes',
  '--target-org',
  'production',
  '--accept-the-terms'
]"

(Same flag was set on global-view, hardcoded-urls, clear-all-cache — confirmed across the log.)

The actual cause the plugin's logger captured but the user-facing error didn't surface — repeated identically across every recipe (org-information, every check command):

"contextInformation": {
  "SoqlQuery": "SELECT Id, Name, IsSandbox, OrganizationType, TrialExpirationDate, NamespacePrefix FROM Organization LIMIT 1",
  "ByPasses": "(empty)",
  "Cause": "The Daily API Request limit has been reached. We cannot continue.",
  "Where": "SalesforceManagerImpl.soqlQuery/_standardSOQLQuery"
}

So the failure is at the very first SOQL query (SELECT FROM Organization LIMIT 1) because our org was past the daily API-request limit at the time. Confirmed by independent probe via sf data query --use-tooling-api -q "SELECT ..." against Limits — DailyApiRequests was at 154,589/123,000 = 125.7% of limit.

Two-layer issue:

1. Real org issue on our side: we exceeded the daily API limit; other integrations were probably silently failing too. That's our problem to investigate — not yours.
2. Plugin UX bug (your side): the user-facing top-level error message is misleading — generic "There was an error while running a SOQL query with the standard queryMore" when the real cause (The Daily API Request limit has been reached) is captured in the JSON contextInformation but never surfaced. The user has to dig into ~/.sf/sf-YYYY-MM-DD.log to find the actual reason.

Suggested fix: in the dataset error wrapper at orgcheck.js:1:141809, propagate the Cause field from contextInformation into the user-facing error message. Something like:

"Failed to run dataset 'org-information' — Cause: The Daily API Request limit has been reached. We cannot continue. (run sf check global-view tomorrow when the limit resets)"

That alone would have saved me the bug-filing trip — I would have just retried today after the 24-hour limit reset.

Happy to test a fix if you point me at the diff.