Skip to content

Any client can send any query #378

Description

@Miracle656

Background

The endpoint accepts arbitrary documents from anyone. Depth (L190) and cost
(L191) limits bound how expensive a single document can be, but they do not
change the fact that an unauthenticated caller composes the query.

For a public exploratory API that is the right trade. For the paid surface — and
after L188, most of this is the paid surface — an allow-list of known documents
is the stronger position: it makes cost predictable, makes caching possible, and
removes the whole class of adversarial-query problems rather than bounding it.

What to build

  • Support persisted queries: a client sends a hash, the server executes the
    document it already knows.
  • Decide whether arbitrary documents stay allowed — in development yes, in
    production it is a judgement call. Make it configurable and default to the
    safer option.
  • A documented workflow for registering a query, or nobody will use it.
  • Persisted queries make response caching tractable, since the document is known
    ahead of time — note that even if you do not implement it.

Acceptance criteria

  • A client can execute a registered query by hash
  • Whether arbitrary documents are accepted is configurable, with a safe default
  • An unknown hash is a clear error
  • Registering a query is documented end to end
  • Tests cover a registered hash, an unknown hash, and the arbitrary-document toggle

Drips Wave · Complexity: Intermediate · 150 points


Repo: Divinity-Labs/Lens. Node + TypeScript, Fastify, mercurius for
GraphQL at POST /graphql, Prisma on Postgres, Redis, Prometheus.

Run the tests: npm test. The tests are vitest, not jest. Running jest
here reports "66 suites, 0 tests" and means nothing. A single file is
npx vitest run src/__tests__/graphqlSubscription.test.ts.

Load test (prices) is already failing on main and has been for some
time. It is not your PR. Everything else should be green.

Read src/__tests__/graphqlSubscription.test.ts before you start. It is the
house pattern for testing this surface and it is good — it drives a real
subscription through a real server and asserts on what a client receives.

This service prices real assets on Stellar mainnet. A wrong number is worse
than a missing one, because the caller cannot tell.

Never elide an address, a contract id or a key in code, comments or test
fixtures. A previous batch shortened a contract id in an issue and five
contributors invented plausible-looking ids to fill the gap. Write it in full or
not at all.


Required: Before submitting, join the contributor Telegram so your work can be tracked and counted toward the Stellar Wave: https://t.me/+fxHXq8f1SwlkZDBk

Activity

  1. KingDavid9999 commented on Oct 16, 2026

    @KingDavid9999

    @KingDavid9999 has applied to work on this issue as part of the Stellar Wave Program's 10th wave.

    Hi maintainer, I'd very much appreciate the opportunity to work on this issue.
    Having reviewed the acceptance criteria, I'm confident that I'd be able to have a PR up shortly after being assigned.
    Kindly assign this issue to me.
    Thank you!

    ℹ️ Repo Maintainers: To accept this application, review their application or assign @KingDavid9999 to this issue.

  2. Senia-Lovo commented on Oct 16, 2026

    @Senia-Lovo

    @Senia-Lovo has applied to work on this issue as part of the Stellar Wave Program's 10th wave.

    Hi Maintainer please I will like to work on this issue

    ℹ️ Repo Maintainers: To accept this application, review their application or assign @Senia-Lovo to this issue.

  3. laxjovial commented on Oct 16, 2026

    @laxjovial

    @laxjovial has applied to work on this issue as part of the Stellar Wave Program's 10th wave.

    Hello maintainer, i would like to work on this issue

    ℹ️ Repo Maintainers: To accept this application, review their application or assign @laxjovial to this issue.

  4. VeronicDev commented on Oct 16, 2026

    @VeronicDev

    @VeronicDev has applied to work on this issue as part of the Stellar Wave Program's 10th wave.

    Hello Maintainer, I can fix this please assign.

    ℹ️ Repo Maintainers: To accept this application, review their application or assign @VeronicDev to this issue.

  5. CollinsKRO commented on Oct 16, 2026

    @CollinsKRO
    Contributor

    @CollinsKRO has applied to work on this issue as part of the Stellar Wave Program's 10th wave.

    Hi Maintainer, I can fix this pls assign. ETA 5hrs

    ℹ️ Repo Maintainers: To accept this application, review their application or assign @CollinsKRO to this issue.

  6. nonchalanttee22-lgtm commented on Oct 16, 2026

    @nonchalanttee22-lgtm
    Contributor

    @nonchalanttee22-lgtm has applied to work on this issue as part of the Stellar Wave Program's 10th wave.

    I'll step in and implement GraphQL persisted queries for Lens (#378)! Restricting execution to pre-registered query hashes (with a configurable toggle for arbitrary queries) locks down the paid surface against adversarial queries, ensures predictable cost, and unlocks response caching.
    Execution Plan
    Persisted Query Store & Resolver Hook (src/api/graphql.ts):
    Support Apollo/Mercurius-compatible persisted query extensions (lookup by query hash/ID in Redis or an in-memory/Prisma registry).
    Configure an environment toggle (GRAPHQL_ALLOW_ARBITRARY_QUERIES, defaulting to false in production, true in development).
    Error Handling & Registries:
    Return a clear, standardized PERSISTED_QUERY_NOT_FOUND error for unknown hashes.
    Documentation & Testing (src/tests/graphqlPersistedQueries.test.ts):
    Document the query registration workflow end-to-end in docs/PERSISTED_QUERIES.md.
    Write Vitest integration tests covering registered hash execution, unknown hash rejection, and the arbitrary-document toggle.
    Assign this issue to me, and I'll submit a clean PR

    ℹ️ Repo Maintainers: To accept this application, review their application or assign @nonchalanttee22-lgtm to this issue.

  7. drips-wave commented on Oct 16, 2026

    @drips-wave

    Congratulations, @nonchalanttee22-lgtm! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on October 22, 2026.

    🧑‍💻 @nonchalanttee22-lgtm: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

    Warning

    When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

    🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

    🌊 Happy Wave 🌊

  8. drips-wave commented on Oct 25, 2026

    @drips-wave

    This issue has been completed by @nonchalanttee22-lgtm as part of the Stellar Wave Program's 10th Wave 🥳

    😎 @nonchalanttee22-lgtm: You earned 150 Points for completing this issue! Once the Wave's rewards are finalized, you'll be eligible for a percentage of the Wave's reward pool based on the percentage of total points you've earned. Learn more here. You can also Leave a review to share your experience working on this issue.

    🧑‍💻 Repo maintainers: How'd the contributor do? Leave a review to share your experience working with them.

  9. Miracle656 commented on Oct 25, 2026

    @Miracle656
    CollaboratorAuthor

    Reopening — this was closed automatically when #478 merged, but #478 does not deliver it.

    That PR routes price subscriptions per pair (#373) and is good work. It adds nothing that restricts which documents a client may send: there is no persisted-query mechanism and no operation allow-list in src/api/graphql.ts, and the new .env.example entries are knobs for the subscription benchmark script, read by scripts/benchmarkSubscriptions.ts rather than the server.

    The depth and cost limits already on main bound how expensive one document can be. This issue is the separate question of whether an unauthenticated caller composes the document at all, which is still open.

    Related: #357 is also still open and was correctly left open — findPair in src/api/graphql.ts still discards the issuer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions