Fix object-list filter preflight plan traversal and argument identification

Open
#613 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
fsharp, graphql

Research direction

Start with the object-list filter request preflight and executable plan traversal, then review the linked pull request discussion for context. Trace deferred, streamed, live, and nested collection plans, and verify inclusion-state handling and identification of the middleware-added nullable ObjectListFilter argument. Done means wrapped and nested filters are coerced while excluded or unrelated filter arguments are accepted.

Written by the indexing model from the issue text.

Description

Description

The object-list filter request preflight does not accurately follow the executable plan and can both miss invalid filters and reject valid requests.

The preflight should traverse deferred, streamed, live, and nested collection plans while only coercing the nullable ObjectListFilter argument added by the object-list filter middleware.

Source: https://github.com/fsprojects/FSharp.Data.GraphQL/pull/612#pullrequestreview-5253463363

Repro steps
  1. Execute a query where an object-list filter is inside an @defer, @stream, or @live wrapper, or inside a nested collection element plan.

  2. Observe that request-level filter coercion can be bypassed.

  3. Execute a query containing an excluded subtree or an unrelated field with an argument such as filter: String.

  4. Observe that the preflight can treat that argument as the middleware's object-list filter and reject an otherwise valid request.

Expected behavior

The preflight should:

  • traverse @defer, @stream, and @live wrappers transparently;
  • traverse collection element plans and nested filtered fields;
  • skip nodes excluded by execution directives;
  • coerce only fields whose definition contains the middleware-added nullable ObjectListFilter argument.
Actual behavior

The traversal stops at wrappers and collection element plans, allowing wrapped or nested list filters to bypass request-level coercion. It also ignores inclusion state and identifies arguments by the name filter, which can incorrectly reject excluded subtrees or unrelated filter arguments.

Known workarounds

Avoid wrapping or nesting object-list-filtered fields and avoid unrelated arguments named filter. These are not practical general-purpose workarounds.

Related information
  • Operating system: All
  • Branch: dev / observed while reviewing task-seq-field-streaming-fixes
  • .NET Runtime, CoreCLR or Mono Version: .NET 10
  • Performance information, links to performance testing scripts: N/A
Dominant language
F#
Stars
406
Forks
74
Avg merge
1d 8h
Merged PRs (30d)
14

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from fsprojects/FSharp.Data.GraphQL

All issues in fsprojects/FSharp.Data.GraphQL

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.