Tutorial: fetching posts throws errors [FIX: broken Prisma2 binary requires clearing ~/.cache/prisma]

Hi there :wave:

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 :slightly_frowning_face:

  • 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 - -
  "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.

I’m not sure how I can debug this… help! :smile:

⇒ node --version

⇒ yarn --version

⇒ redwood packages: 0.2.5


Hi @olance Sorry you’re having difficulty and hope we can get you sorted!

First off, I want to check if you’re using Firefox – there’s a known issue if so.

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?

Thanks for the quick reply @thedavid!

Sorry I should have included browser & all… it was late :sweat_smile:
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 :man_shrugging:

I have pushed everything, in its current state, on Github: https://github.com/olance/redwood-blog-tutorial

Let me know if I can help debug this in any way!

Does yarn rw db generate run successfully?

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 :crossed_fingers:

@rob yes it did work:

⇒  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 :sob:

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 :slight_smile:

I don’t get it :expressionless:

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 :confused:

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 :slightly_frowning_face:

The service code is called. The GraphQL query is executed. But when comes the time to getting values, things fail silently.


:point_up_2: 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 :expressionless:

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!

… latest news :smile:

I have successfully created a new working project on another computer. Copied the project over to my main one. It worked!

Then I deleted dev.db and node_modules, followed by the commands you gave me and … not working anymore! :confused:

So is Prisma generating something buggy in some way?

@olance First off, you’re a champion! I would have given up a long time ago. Thank you so much for hanging in there with us :trophy:

And agreed this behavior is both frustrating and suspicious. Especially given the different types of setup testing you’ve attempted.

I’ve forked your reproduction repo and committed one change: I generated dev.db, confirmed it’s working, and added it to the repo. Could you:

  1. git clone https://github.com/thedavidprice/redwood-blog-tutorial
  2. yarn
  3. yarn rw dev

Then navigate to http://localhost:8910/posts --> is it working?!? :crossed_fingers:

If so, next step delete 1) prisma/migrations/ as well as 2) prisma/dev.db and repeat the steps:
yarn rw db save
yarn rw db up
yarn rw dev

Then what happens??? :grimacing:

Well, first I’m quite stubborn and don’t like to be defeated by a computer :grimacing:
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 :slight_smile:

It’s not :disappointed:

So I tried something else, and found that my intuition was correct!

  1. I copied over, again, the project I had created on another machine and made sure it still ran OK: :white_check_mark:
  2. I stopped the server in that project and started yarn rw dev again in yours: :x:
  3. Stopped the server
  4. Copied node_modules/@prisma/client/runtime/query-engine-darwin from my working project to yours
  5. yarn rw dev: :white_check_mark:
  6. Delete node_modules/@prisma/client/runtime/query-engine-darwin
  7. yarn rw up regenerates query-engine-darwin
  8. yarn rw dev: :x:

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…

The search continues … :male_detective:t2:‍♂

1 Like

You are an animal. :tiger2: And hang in there 'cause I think we’re getting close!

This wouldn’t be the first time we’ve had a super strange issue with a Prisma2 binary:

Could you take the solution in that thread for a spin and report back? Also, looping in the Prisma team about this as well.

Well actually… things are working now :smile:

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!! :partying_face: :tada:

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:

Mon, 23 Mar 2020 18:06:09 GMT

Too much of an early adopter, I guess :stuck_out_tongue_closed_eyes:

1 Like

Just wow… And I owe you so many :beers: along with the :partying_face: :tada:

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. :man_facepalming:

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 :rocket:

1 Like

Well, you know the saying…

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 :crossed_fingers: :slight_smile:


Get some rest! You’ve earned it.

#NoFear :stuck_out_tongue:


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 :confused:

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!

1 Like

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…