Closed BradDC closed 4 years ago
Additional Information: tested with prisma2@2.0.0-preview-9 tested with prisma2@2.0.0-alpha.155
I can't reproduce this.
I deployed the exact same code here: https://zej6qrc3za.execute-api.ap-southeast-2.amazonaws.com/prod/
You will need to view it via a GraphQL API client eg graphql playground desktop or insomnia
It works:
Can you please check the logs and see the underlying issue?
logs simply indicate the lambda process timed out, the mutation used in your example looks different to the sample, are you working from a different example codebase?
11:50:54 am
START RequestId: 32c818b5-2fa2-4071-8d98-585dfffe3542 Version: $LATEST
11:51:04 am
END RequestId: 32c818b5-2fa2-4071-8d98-585dfffe3542
11:51:04 am
REPORT RequestId: 32c818b5-2fa2-4071-8d98-585dfffe3542 Duration: 10010.15 ms Billed Duration: 10000 ms Memory Size: 1024 MB Max Memory Used: 87 MB
11:51:04 am
2019-09-04T23:51:04.950Z 32c818b5-2fa2-4071-8d98-585dfffe3542 Task timed out after 10.01 seconds
My logs are fine:
I think we changed the connect mechanism in one of the recent releases. Can you please make sure that you are on the latest version of prisma2. Rerun prisma2 generate
and try deploying this app
@BradDC Can you use the native Postgres connector and try to make a connection from your lambda. Could it be that it is a permission issue and the DB is not accessible from Lambda function?
Hello,
I think I am facing the same issue withprisma2@2.0.0-preview014.1
. If the request is "too large" it ends with time out.
I'm deploying on Zeit Now. Some requests respond 200, others 502. No issue on local.
2019-10-18T10:20:38.854Z b1976ac4-41a1-4150-b162-a8c898153ade Task timed out after 10.01 seconds
You can try : https://quiet-5xp2jkb4f.now.sh/graphql
{
collections(first:20){
id
name
owner {id}
}
}
Take first 5, it works (even if it's long).
I tried to debug with now dev
but definitely works locally.
On the free plan, the lambda execution time of Zeit now is limited to 10 secs so that is why it is failing for first: 20
.
Where is your database hosted though? It feels pretty slow for this operation.
Locally there is no limit, so it works fine.
The workaround here would be to get a paid zeit plan.
Ah yep, you're right! My DB is an RDS instance. It's really slow indeed, can't not figure out, why? My first assumption is that my query requests nested models and photon does not solve n+1 problem. Is that make sense?
I can't tell that without seeing your GraphQL implementation.
Note that currently, nexus prisma does introduce N+1 which we will solve before GA.
Yes, I noticed that. I am using graphql-yoga and nexus. I am newcomer in prisma & graphql ecosystem, I may missing something. It seems that implementation is quite basic
Your implementation looks fine. So preview software and slow RDS is to blame here.
The performance will increase in the coming weeks so stay tuned.
I am closing this one in favor of https://github.com/prisma/photonjs/issues/272 as it has a better reproduction.
I noticed that the last comment on this issue was in October, since then, we have made many performance improvement.
If you have an issue that is urgent/not covered by #272 or this. Please post a comment on #272 and tag me.
Thank you 🙂🙏
Sample with reproducible issue: https://github.com/BradDC/graphql-broken
Description: This appears to affect only graphql in combination with photon specifically with aws lambda, when run locally there is no issue. It appears that data is returned normally from photon but the process might be continuing indefinitely eventually resulting in a timeout.
ref: https://github.com/prisma/prisma2/blob/master/docs/photon/api.md#debugging # Recommendation is to run photon.disconnect() - is there a good place to do that in the context of a graphql lambda server.
serverless.yml includes 3 paths as below.
✅path: /photon - working test of pure photon only call with plain http return.
❌path: / - full graphql lambda server including nexus, not working suspect as no location to run photon.disconnect() ?
❌path: /graphql - simplified graphql service, returns and works correctly only if photonTest.disconnect() is called after.