Describe the bug
Pagination (after and before) doesn't work for id field type UUID.
Issue #2615 states that UUIDs are supported as IDs. However, the current documentation (1.13) doesn't list UUID scalar field types anymore.
To Reproduce
Steps to reproduce the behavior:
type Y {
id: UUID! @unique
value: Int
}
Y.{
"data": {
"ies": [
{
"id": "26247034-a0c6-4b30-861d-504bc59ddf54",
"value": 3
},
{
"id": "41c597fe-2c78-4af6-bd8f-ab8107e90898",
"value": 5
},
{
"id": "6bc1691c-fa91-49fa-982d-c7fd53fa59d3",
"value": 1
},
{
"id": "eb1743e9-d0a5-4123-8142-50fb33ac89bc",
"value": 4
},
{
"id": "f7290046-e962-488e-9c32-cc60b943a990",
"value": 2
}
]
}
}
query GetY($after: String, $before: String, $first: Int, $orderBy: YOrderByInput) {
ies(after: $after, before: $before, first: $first, orderBy: $orderBy) {
id
value
}
}
GetY with variables:{
"first": 1
}
results as expected:
{
"data": {
"ies": [
{
"id": "26247034-a0c6-4b30-861d-504bc59ddf54",
"value": 3
}
]
}
}
GetY with variables:{
"first": 1,
"after": "26247034-a0c6-4b30-861d-504bc59ddf54"
}
results in error
{
"data": null,
"errors": [
{
"message": "Whoops. Looks like an internal server error. Search your server logs for request ID: local:api:cjkk6bqnu002c08297fgixhit",
"path": [
"ies"
],
"locations": [
{
"line": 2,
"column": 3
}
],
"requestId": "local:api:cjkk6bqnu002c08297fgixhit"
}
]
}
GetY with variables:{
"first": 1,
"before": "eb1743e9-d0a5-4123-8142-50fb33ac89bc"
}
results in the same error as in 5.
Expected behavior
A correctly paginated return as provided when using types featuring an id of type ID.
Versions (please complete the following information):
prismagraphql/prisma 1.13 358d83735689
postgres 10.4 978b82dc00dc
Additional context
Prisma server logs error:
prisma_1 | org.postgresql.util.PSQLException: ERROR: operator does not exist: uuid = character varying
prisma_1 | Hint: No operator matches the given name and argument type(s). You might need to add explicit type casts
prisma_1 | Position: 198
prisma_1 | at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2433)
prisma_1 | at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2178)
prisma_1 | at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:306)
prisma_1 | at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:441)
prisma_1 | at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:365)
prisma_1 | at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:155)
prisma_1 | at org.postgresql.jdbc.PgPreparedStatement.executeQuery(PgPreparedStatement.java:118)
prisma_1 | at com.zaxxer.hikari.pool.ProxyPreparedStatement.executeQuery(ProxyPreparedStatement.java:52)
prisma_1 | at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.executeQuery(HikariProxyPreparedStatement.java)
prisma_1 | at com.prisma.api.connector.jdbc.database.BuilderBase.$anonfun$queryToDBIO$1(BuilderBase.scala:51)
prisma_1 | at com.prisma.api.connector.jdbc.database.BuilderBase.$anonfun$jooqToDBIO$1(BuilderBase.scala:81)
prisma_1 | at slick.jdbc.SimpleJdbcAction.run(StreamingInvokerAction.scala:70)
prisma_1 | at slick.jdbc.SimpleJdbcAction.run(StreamingInvokerAction.scala:69)
prisma_1 | at slick.basic.BasicBackend$DatabaseDef$$anon$2.liftedTree1$1(BasicBackend.scala:275)
prisma_1 | at slick.basic.BasicBackend$DatabaseDef$$anon$2.run(BasicBackend.scala:275)
prisma_1 | at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
prisma_1 | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
prisma_1 | at java.lang.Thread.run(Thread.java:748)
Can confirm. Also appears when using prisma:1.15-alpha-1.
@marktani, would it be possible to estimate how complex this issue is? Would it be something that can be fixed in an upcoming release, or are there deeper underlying problems with UUIDs in Prisma? Thanks!
I haven't reproduced this yet, so it's difficult to give an estimation. I don't think this will make an upcoming release.
We are likely tackling this and other issues with UUID in the Postgres connector together soon.
I can confirm this bug on 1.19-beta using the Postgres connector.
We implemented a fix and shipped it with 1.19.0.
Most helpful comment
We implemented a fix and shipped it with
1.19.0.