Determine which field is causing constrain error response

General
1

Hello,
The case as following,
Considering
Schema:

type User {
id: ID!
fullName: String!
userName: String! @unique
email: String! @unique
}
Database:
{
id: 1
fullName: private doe
userName: private doe
email: email@test.com
}
When I try to create new user with the same userName, email or both, the error response is not clear about which field is causing the issue and it's something like this:
{
"errors": [
{
"message": "Constraint validation failed",
"locations": [ {
"line": 6,
"column": 3 } ],
"path": [
"createUsers"
],
"extensions": {
"code": "INTERNAL_SERVER_ERROR",
"exception": {
"stacktrace": [ "Neo4jGraphQLConstraintValidationError: Constraint validation failed" ] } }
} ],
"data": null
}
FOR INPUT:
{
"input": [
{
"fullName": "private doe ",
"userName": "private doe",
"email": "email@test.com",
}
]
Is there a way to know which field exactly is causing the error to be thrown ?
Any ideas, thoughts to achieve this or even work around would be very appreciated,
Thanks

2

Hi @Mreda ,

As far as I can see, you are creating a uniqueness constraint on userName and email properties. Therefore, when you try to add another record with the same values it will conflict. If you want to be able to add the same values again (having duplicates), you have to remove the unique constraint from the DB.

Regards,

Busymo

3

I want to know which field is being sent as a duplication in the database in the response

for example a request with the data like in the description, I want to know if there's a way that the response tells me that both userName, email is already in the database,
Thanks

4

Hi @Mreda,

Yes, you could do a query for that like this:

MATCH (u:User)
WHERE u.email = $email OR u.userName = $userName
RETURN true, u

Check it out and see if it fulfils your requirements.

5

I mean the response for the request when the user requesting to insert duplications,
I want to return to FE which field is causing the error throwing, nothing to query,
Please let me know if that's clear enough,
Thanks

6

Hey @Mreda, this is working as intended and when implemented was somewhat of a security decision to not report which data already exists in the database to frontend clients. However, this behaviour could be reviewed, so I've raised a feature request in our repo so that we discuss it at some point. However, I'm afraid there is not currently a workaround.

7

Seems ridiculous not to at least include a debug mode for devs to know which field it is referring to.