-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AA User I can run intensive mutations without getting an error #6025
Comments
Implementation Steps
References |
See #6023 as a "temporary" solution. |
Weiko
added a commit
that referenced
this issue
Jun 26, 2024
We are exposing the server mutationMaximumRecordAffected value via clientConfig so it can be used by the FE. This is a first step for #6025 <img width="610" alt="Screenshot 2024-06-26 at 14 58 26" src="https://github.com/twentyhq/twenty/assets/1834158/9d192976-fd22-45d2-bdaa-a8ff6bb90ca2">
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Scope & Context
Currently we have a limitation on the API - MUTATION_MAXIMUM_RECORD_AFFECTED, defined as an env variable - which specifies the number of records that can be affected during a GraphQL mutation (most specifically update and deletions mutations, creations are not concerned for some reason).
This limitation comes from pg_graphql limitation, see "atMost" in the documentation here https://supabase.github.io/pg_graphql/api. If it's not specified, it falls back to the default value (60).
This is also a good practice to avoid overloading the server and in this case the DB. This also tells the user "We handle this much so you should expect an acceptable timeframe for your request, more of it might result in degraded performances/timeout."
Current behavior
For example, when we try to delete more than {MUTATION_MAXIMUM_RECORD_AFFECTED} records, we get an error, which is fine from the API point of view but the Frontend should handle this properly, this is even more an issue UX wise when people want to check the box at the top of the table which implies that it should select all records and mutation affects all of them (even those that are not loaded yet).
Expected behavior
We still want to keep a limitation on the API but we should handle intensive mutations on the client with some strategies:
MUTATION_MAXIMUM_RECORD_AFFECTED). (e.g: MUTATION_MAXIMUM_RECORD_AFFECTED=160 means we will paginate our mutations with 160 records per page until all records have been affected). The UI should reflect this, similarly to the csv export, with pagination/percent view.
Technical inputs
The text was updated successfully, but these errors were encountered: