I’m following the tutorial and have just been generating the scaffold for my Post model.
However, things aren’t working in the /posts page
The “Loading…” message displays for a while, and then the page changes to the FatalErrorPage
On the logs side, I’m seeing this error:
00:52:15 web | [HPM] Error occurred while trying to proxy request /graphql from localhost:8910 to http://localhost:8911 (ECONNRESET) (https://nodejs.org/api/errors.html#errors_common_system_errors)
The API server is definitely running and actually receives the proxied request… but it times out:
00:52:15 api | POST /graphql - - ms - -
If I browse to http://localhost:8911/graphql/ and try sending a query, it spins for (long) while to finally error out with :
{
"error": "Failed to fetch. Please check your connection"
}
Again, the API server does receive the request but times out.
Note that the IntrospectionQuery queries from GraphiQL, sent every 2 seconds or so, are correctly handled by the API server.
Otherwise, most of the time this issue is due to either code being incorrect or the database migration getting out of sync with code changes. Could you take a look at this comment (and thread if needed) and see if these steps help you get sorted?
If that doesn’t seem to help either, could you confirm your OS and version?
Sorry I should have included browser & all… it was late
I’m using Chrome, latest version, on macOS Mojave (10.14.6).
Unfortunately the Github issue/discussion did not help.
I tried deleting the sqlite db and generated migration, and running db save and db up again, but still getting the same result:
11:20:57 api | POST /graphql - - ms - -
11:20:57 web | [HPM] Error occurred while trying to proxy request /graphql from localhost:8910 to http://localhost:8911 (ECONNRESET) (https://nodejs.org/api/errors.html#errors_common_system_errors)
Given the logs from both the web and api process, I’d say it’s probably not a browser-related error, but rather something to do with GraphQL / the DB.
And given the fact that Graphiql manages to get a response to its IntrospectionQuery queries, I’d bet on the DB ^^
Also, it’s possible that my setup is not so clean; I have installed Node and Yarn a long time ago with different methods… I cleaned things up before installing Redwood, but who knows
Hi @olance Thank you for the link to your repo. Good news! I was able to get this running locally.
The problem seemed to be your db migration being out of sync with your code. But it’s possible something else got out of sync on your end between the db state, code state, and your modules. Could you try this:
Note: before these steps, make sure you have “git commit’ed” any file changes you want to keep
$ git clean -fxd
This will remove all files ignore by git or any file changes not committed (so node_modules and the local dev db). It’s like starting the package installation from scratch.
$ yarn install
Re-install node packages
$ yarn rw db save
This creates a “snapshot” of your db schema, which you need to match your current schema.prisma
$ yarn rw db up
This applies the “snapshot” to your db, which in your case is the local dev db running sqlite
$ yarn rw dev
You should be ready to go! Head to /posts and let me know if it works
⇒ yarn rw db generate
yarn run v1.22.4
$ /Users/olance/Documents/Dev/redwoodblog/node_modules/.bin/rw db generate
Generating the Prisma client... [started]
$ /Users/olance/Documents/Dev/redwoodblog/node_modules/.bin/prisma2 generate
✔ Generated Prisma Client to ./../node_modules/@prisma/client in 49ms
You can now start using Prisma Client in your code:
import { PrismaClient } from '@prisma/client'
// or const { PrismaClient } = require('@prisma/client')
const prisma = new PrismaClient()
Explore the full API: http://pris.ly/d/client
Generating the Prisma client... [completed]
✨ Done in 1.87s.
@thedavid Executed all the different steps and still no luck
As a side note, I followed the tutorial instructions to the letter and haven’t executed anything else than what was instructed.
So it must be a machine setup issue.
I’m gonna try again in a node Docker container, see how that works, and report back
Within a Docker container, everything worked flawlessly.
I removed and reinstalled everything Node-related on my Mac, recreated the tutorial project from scratch, and it’s still hanging on the Graphql posts query
I’ve spent hours debugging deep into the API dev-server code, but can’t figure out what the hell is going on on my machine
The service code is called. The GraphQL query is executed. But when comes the time to getting values, things fail silently.
That’s where I get to (node_modules/graphql/execution/execute.js).
data is first a pending Promise, so the first breakpoint in the screenshot hits.
I’d expect the second breakpoint to hit soon afterwards, as the Promise resolves, but when I “continue” the code execution, it goes on without breaking there, and the error I’ve shown earlier appears in the server logs.
None of my attempts to console.log any error from a catch on the Promise worked/showed anything
I could still setup everything to work from within a Docker container, but I’d rather not… let me know if you’ve got any ideas!
Well, first I’m quite stubborn and don’t like to be defeated by a computer
And second, Redwood looks like what I’ve been waiting for in the JS world for like, forever (i.e. ~ Rails for JS). So yeah, hanging in there
It’s not
So I tried something else, and found that my intuition was correct!
I copied over, again, the project I had created on another machine and made sure it still ran OK:
I stopped the server in that project and started yarn rw dev again in yours:
Stopped the server
Copied node_modules/@prisma/client/runtime/query-engine-darwin from my working project to yours
So clearly, for some reason, Prisma does not generate a correct runtime on my machine.
What’s strange is that it’s a binary. I doubt they’re compiling it on the fly, rather than just fetching/copying the correct pre-built binary depending on the declared binaryTargets for photonjs?
Indeed there’s @prisma/engine-code and @prisma/sdk and others with code that shows the engine is downloaded on-demand
A diff between both yarn.lock files of working and non-working projects shows no differences, so both engine binaries have been fetched by the exact same version of Prisma
A binary diff of both engine binaries shows that they are different: there’s at least a 3MB chunk of data in one, that is only a bunch of zeroes in the other…
It was definitely the binary.
After some digging around in Prisma’s issues, I tried clearing its cache:
$ rm -rf ~/.cache/prisma
After that, removing node_modules (that a bit radical but… whatever ^^) and running yarn again reinstalled everything. yarn rw dev aaaaaand … it works!!
At first I was surprised to see things work because I did not believe I had actually deleted anything prisma-related in the cache folder (forgot to check for presence of the prisma dir…).
I reinstalled the Prisma packages to try and understand what part was downloaded, from where and when… and realized things were now working.
Now the funny part is: the content of ~/.cache/prisma/master/45bc4bb9bcdd5fd45ffd3bc2a1b42cd0d4a4ae0a/darwin/lastModified-query-engine is presumably the last modification date of the engine binary:
I can only hope your work here will pay forward in pain avoidance for many others to come!
So most likely the binary was busted/corrupted from the beginning but stored in the cache.
I so hope for smooth travels from here out! And that you enjoy all the Redwood goodness that is working for you. But, ahem, just a heads up… we just updated to Prisma2 preview024 in ‘master’ branch. More “early adoption” adventures coming your way soon
There are only two hard things in Computer Science: cache invalidation and naming things.
Thanks for the continued support & suggestions throughout the resolution of the issue!
I’ve been able to continue the tutorial down to form creation… time to sleep for me, but I’m sure things will be much smoother now
Thanks for fighting through this @olance. As written otherwise, you seem to be the third real world occurence of https://github.com/prisma/prisma2/issues/1819. Thanks so much for keeping at it, now we have a third person to ask if our fixes actually helped here, as this is super difficult to reproduce and understand
If someone lands here via Google because they have strange things going on with Prisma and SEGFAULTs (or invisible errors), this represents our current understanding of the situation and what we are doing to fix it: https://github.com/prisma/prisma2/issues/1819#issuecomment-603406808
@janpio I’m glad if that could help even a little!
I’m going to follow-up on the Github issue, hopefully you’ll get a better understanding of what’s going on!
I too have been getting intermittent errors of this nature:
web | [HPM] Error occurred while trying to proxy request /graphql from localhost:8910 to http://[::1]:8911 (ECONNRESET) (Errors | Node.js v16.2.0 Documentation)
When I do not get the error I see this in the api log
api | POST /graphql 200 1.853 ms - 109
When I do get the error the api logs shows:
api | POST /graphql - - ms - -
I’m working in a 0.31 ts project with the Firebase auth integration
So far I’ve been able to clear the error by fiddling with the last code I fiddled with… It’s too bad that whatever is blowing up is unreported in the console…
That’s where I get to (
And hang in there 'cause I think we’re getting close!
along with the 
