hasura / hasura/graphql-engine

constraint-violation paths are incomplete

Open
#8,035 2 comments 7 reactions 0 assignees View on GitHub
k/bug
Dominant language
TypeScript
Stars
32.1k
Forks
3k
PR merge metrics
PR metrics pending

Description

### Version Information

Server Version: 2.1.1
CLI Version (for CLI related issue): 2.1.1

### What is the expected behaviour?

If a mutation fails due to a database constraint, I expect the error response to provide enough data to programmatically determine the problematic field without having to parse the exception message.

### Keywords

mutation,constraint-violation

### What is the current behaviour?

Assuming there's a database table named _profiles_ with fields `(id, name, rank)` and the _name_ field has a uniqueness constraint, then when I execute the following mutation with a duplicate name, the resulting error response does not include the _name_ field in the _path_ value.

```graphql
mutation CreateProfile($id: uuid!, $profileName: String!, $rank: String!) {
insert_users(
objects: { name: "DUMMY", profiles: { data: { id: $id, name: $profileName, rank: $rank } } }
on_conflict: { constraint: users_auth0_id_key, update_columns: last_seen }
) {
returning {
profiles {
id
}
}
}
}
```

The error response looks like:

```js
{
code: "constraint-violation"
​​​​​​ path: "$.selectionSet.insert_users.args.objects[0].profiles.data"
}
```

The last path component is _data_, which means it could be any of the input variables. That's not terribly helpful information. The _path_ value should be `$.selectionSet.insert_users.args.objects[0].profiles.data.name`.

### How to reproduce the issue?

1. Create a table with a unique column
2. Execute a mutation with variables that would violate the uniqueness constraint in step 1.
3. Observe the _path_ value in the GraphQL response

### Any possible solutions?

The error message is `Uniqueness violation. duplicate key value violates unique constraint "profiles_user_id_name_key"`. The message is not structured data and both Hasura and PostgreSQL are free to change the message whenever they'd like, so relying on it is problematic. However, it does indicate the name of the database constraint that was violated and for now that's sufficient enough to identify the validation error in client code.

### Can you identify the location in the source code where the problem exists?

No.

### If the bug is confirmed, would you be willing to submit a PR?

Maybe.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.