[krynju]

jh project list has failed on every JuliaHub instance since v0.4.3:

$ jh project list
Failed to list projects: GraphQL errors: [{query is not allowed}]

Why

JuliaHub answers only allowlisted GraphQL documents. Before #57 the CLI sent JuliaSim's allowlisted Projects document. #57 added paging and a server-side filter, and along the way trimmed fields from projects.gql. The trimmed text matches no allowlisted document, so every instance rejects it. Hasura did the same before graphqlsrvr replaced it.

#57 trimmed the fields for a good reason: JuliaSim's document selects resources, which is expensive. It's still expensive on graphqlsrvr. Timed as admin on nightly.juliahub.dev (61k projects):

allowlisted document	20 rows	100 rows
JuliaSim (juliasim-projects.gql)	24.4 s	504 after 60 s
web UI (frontend/src/components/Projects/queries/projects.gql)	0.5 s	0.5 s

So the CLI now sends the web UI's Projects document for listings. Only two versions of it exist on release branches from 6.9 on, and each of those releases allowlists exactly one. jh clone looks up a single owner/name, so it can afford JuliaSim's document as a last resort: that reaches 6.7 and 6.8, where jh clone worked before this PR. Checked with graphqlsrvr's allowlist Lookup against each release's metadata:

release	projects.gql (26.4+ web UI)	projects_pre264.gql (6.9–26.3 web UI)	projects_juliasim.gql (clone only)
6.7, 6.8	no	no	yes
6.9, 25.7, 25.8, 25.10, 26.1, 26.2, 26.3	no	yes	yes
26.4, 26.5, master	yes	no	yes

The CLI sends projects.gql and, when a server rejects it, projects_pre264.gql. "Rejects" means query is not allowed, or a validation-failed "field ... not found in type: 'projects'" from a pre-26.4 server running without an allowlist, whose schema lacks the 26.4 fields. Any other error is returned as it is. If every document is rejected, all the errors are reported. Neither web UI version selects resources, so a listing's fallback is as fast as the first try. Listings never use JuliaSim's document. On 6.7/6.8 jh project list stays unsupported, as it was before this PR. The clone lookup sends JuliaSim's document only after both web UI documents are rejected. It sends it with the owner/name filter and a 10-row limit, which keeps the resources cost to a row or two.

What changed

• projects.gql and projects_pre264.gql are the two versions of the web UI's Projects document (listDocuments). lookupDocuments adds projects_juliasim.gql, which has the same text as graphqlsrvr/external-queries/juliasim-projects.gql. One fetchProjectsWith tries a list in order. The go:embed comment and CLAUDE.md say the files must stay the server's text, and why listings never use JuliaSim's.
• jh clone owner/name had its own hand-pasted copy of the query, sent with only ownerId: no limit and no filter. graphqlsrvr caps that at 1000 rows, so on a big install the target could be missing from the page. It now goes through lookupDocuments with a server-side owner/name filter (projectLookupFilter, literal and case-insensitive, sharing ownerUsernameFilter with project list --user). An exact match wins, then the only case-insensitive one. Several case-variant matches without an exact one are reported as ambiguous, and a row that matches neither is not picked. The copy, its separate HTTP client and a second getUserInfo round trip are gone.
• e2e: skipIfUnsupported and backendGap treated "not allowed" as a backend gap and skipped. That's why TestProjectList and TestProjectListByUser skipped on both nightly installs instead of failing. A disallowed document is a CLI defect, so a single disallowedQuery helper now makes it fail in both. TestCloneNotFound runs the clone lookup against the live server and expects "not found". The README and the package test header say so, and that the suite targets JuliaHub 25.10+, where the allowlist carries the CLI's current Groups and Users documents.
• Unit tests:
  • TestProjectsDocumentsUnchanged pins all three documents' normalized text and rejects resources in the listing documents. It is a change detector only, because this repo can't see the server's allowlist.
  • The TestFetchProjectsPage* tests cover the fallback: the 26.4+ document first; fall back on query is not allowed or a missing project field only (not on filter validation errors); which documents were sent; and that both errors are kept when neither is accepted.
  • TestLookupProjects* cover the clone lookup's JuliaSim fallback and its 10-row limit. TestPickProject and TestProjectLookupFilter cover choosing the row.

Evidence

• All three documents checked with JuliaHub's own graphqlsrvr/internal/allowlist Lookup on master and every release from 6.7 (table above). v0.4.3's text matches nothing anywhere. projects_pre264.gql is byte-identical to release-26.3's web UI file.
• Live on nightly.juliahub.dev:

  project list, 100 rows, admin             200   0.5 s
  clone lookup  owner=TEST name=<existing>  200   rows=1, the right project, 0.25 s
  clone lookup  name=zz_no_such_project     200   rows=0
  v0.4.3 projects.gql                       200   errors: query is not allowed
  

• go vet ./..., go test ./... and go test -tags e2e -c ./e2e pass.

Not in this PR

• package_search.gql / package_search_count.gql are allowlisted up to 26.3 but not from 26.4. Package search uses REST first, so only the GraphQL fallback is dead on newer servers. The e2e package and search packages tests skip that case by name (skipIfPackageUnsupported) instead of failing, and the README says so.
• Server side: JuliaComputing/JuliaHub#25293 adds jh-projects.gql to graphqlsrvr/external-queries/, with the same text as projects.gql. That keeps the 26.4+ document allowlisted when the web UI's file changes, the way jh-users.gql and jh-groups.gql already work.

🤖 Generated with Claude Code

[pankgeorg]

Can we add an integration test as part of the JuliaHub release tests?

[krynju]

Can we add an integration test as part of the JuliaHub release tests?

we have jh running as part of nightly, that's how i caught it