ash-project / ash-project/ash_graphql

[Relay] Issue with subscriptions on read_actions which have auth filters and pagination

Open
#350 0 comments 0 reactions 0 assignees View on GitHub
bug
Dominant language
Elixir
Stars
97
Forks
101
Avg merge
12h 51m
Merged PRs (30d)
5

Description

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

### AI Policy

- [x] I agree to follow this project's AI Policy, or I agree that AI was not used while creating this issue.

### Versions

Ash Graphql 1.8.2

### Operating system

Mac

### Current Behavior

I discovered an issue with subscriptions with read_actions where there are authorization filters and the read action has pagination setup (common when using Relay).

When this happens, the record gets added to the list of records which need to be refetched to assure the actor is authorized to see it. In the resolver, we call [do_refetch](https://github.com/ash-project/ash_graphql/blob/main/lib/graphql/resolver.ex#L664) on those records, which ends up [calling](https://github.com/ash-project/ash_graphql/blob/main/lib/graphql/resolver.ex#L850) Ash.read with the query. Unfortunately, if the read action has pagination, the Ash.read correctly returns an {:ok, Ash.Page.Keyset} (or Offset), which then crashes because the resolver is expecting `{:ok, []}` type results.

Fortunately there's an easy workaround, which is to update the read action pagination so that `required?` is false (which I didn't know was an option!). Another workaround is to have a separate read action which doesn't have pagination, and use that for the subscription.

I wonder if this is something that should be fixed in the resolver to handle Keyset or Offset returns (but then do we iterate all the records?), or is there a way to specifically tell Ash to skip pagination (even if it's required?), or maybe just a limitation that should be documented?

### Reproduction

_No response_

### Expected Behavior

_No response_

Contributor guide

Open the contributing guide

Research direction

Start in lib/graphql/resolver.ex at do_refetch around line 664 and the Ash.read call around line 850. Reproduce the subscription flow with an authorization filter and a required paginated read action, then determine the supported handling for Ash.Page.Keyset or Ash.Page.Offset and verify that the resolver no longer crashes or that the limitation is documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
elixir, graphql
Domain
api, authorization
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.