Infinite loop GET /__REMIX_ASSETS_MANIFEST 200 - -

[arnaudambro]

What version of Remix are you using?

1.14.0

Are all your remix dependencies & dev-dependencies using the same version?

• Yes

Steps to Reproduce

Here is my package.json

{
  "sideEffects": false,
  "scripts": {
    "build": "run-s build:*",
    "build:remix": "remix build",
    "release-sentry": "remix build --sourcemap && node ./node_modules/@sentry/remix/scripts/sentry-upload-sourcemaps.js && rm ./public/**/*.map",
    "dev": "run-p dev:*",
    "dev:build": "cross-env NODE_ENV=development remix dev",
    "dev:serve": "cross-env NODE_ENV=development nodemon --watch build node_modules/.bin/remix-serve build",
    "lint": "eslint --cache --cache-location ./node_modules/.cache/eslint .",
    "start": "remix-serve build",
    "clean-build-and-cache": "rm -rf ./.cache && rm -rf ./build && rm -rf ./public/build",
    "clean": "npm run clean-build-and-cache && npm install",
    "web:dev": "vite",
    "web:build": "vite build --emptyOutDir",
    "web:preview": "vite preview"
  },
  "dependencies": {
    "@remix-run/node": "^1.14.0",
    "@remix-run/react": "^1.14.0",
    "@remix-run/serve": "^1.14.0",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
  },
  "devDependencies": {
    "@remix-run/dev": "^1.14.0",
    "@remix-run/eslint-config": "^1.14.0",
  },
  "engines": {
    "node": ">=14"
  }
}

Expected Behavior

Everything should be alright

Actual Behavior

When refresh, there is an infinite call to GET /__REMIX_ASSETS_MANIFEST

[machour]

What command are you using to run your project?

[arnaudambro]

npm run dev

[cmd-johnson]

I'm encountering this, too. I'm running the new dev server with the Remix App Server like instructed in the release notes.

I didn't have time yet to get to the bottom of this, but at least it looks like the requests aren't coming from the browser, because the network tab is empty.

It also doesn't appear to break anything (other than spamming the console with GET /__REMIX_ASSETS_MANIFEST 200 - - 0.599 ms lines)

[kiliman]

I had the same issue, and it appears to be a problem when using Remix App Server.

When I ejected to express, it worked fine and I was able to use HMR.

BTW: You can eject from RAS to Express with my script:

npx rmx-cli eject-ras
https://rmx.fyi/ejectras

[dmarkow]

I'm having the issue on an express dev server. It happens maybe once or twice per day. I think it has to do with saving, then saving another change before the first rebuild is done, but I'll need to dig in further.

[dmarkow]

Following up on my comment above, I can reliably get this to happen 100% of the time if I save a change while a rebuild is in process. For example, if I save a file, realize there was a typo, and quickly fix it and save again. Since my app rebuilds take 2+ seconds, it's easy for the second save to happen before the rebuild is done. Doesn't matter if I use node --watch or nodemon:

$ run-p dev:remix dev:serve
$ NODE_ENV=development remix dev
$ PORT=3000 NODE_ENV=development node --watch-preserve-output --watch server.js

Remix server listening on port 3000 development
💿 File changed: app/routes/#.tsx
💿 Rebuilding...
💿 File changed: app/routes/#.tsx # This is my second save while the first rebuild is still happening
💿 Rebuilding...
💿 Rebuilt in 2.5s
💿 Waiting for http://192.168.1.111:3000...
GET /__REMIX_ASSETS_MANIFEST 200 4.529 ms - -
Restarting 'server.js'
💿 Rebuilt in 2.2s
💿 Waiting for http://192.168.1.111:3000...
Restarting 'server.js'
Remix server listening on port 3000 development
GET /__REMIX_ASSETS_MANIFEST 200 4.350 ms - -
GET /__REMIX_ASSETS_MANIFEST 200 2.515 ms - -
💿 http://192.168.1.111:3000 ready in 1.1s
GET /__REMIX_ASSETS_MANIFEST 200 2.963 ms - -
GET /__REMIX_ASSETS_MANIFEST 200 3.791 ms - -
GET /__REMIX_ASSETS_MANIFEST 200 3.970 ms - -
GET /__REMIX_ASSETS_MANIFEST 200 4.211 ms - -
GET /__REMIX_ASSETS_MANIFEST 200 5.480 ms - -
GET /__REMIX_ASSETS_MANIFEST 200 5.687 ms - -
GET /__REMIX_ASSETS_MANIFEST 200 7.635 ms - -
GET /__REMIX_ASSETS_MANIFEST 200 7.261 ms - -
GET /__REMIX_ASSETS_MANIFEST 200 6.873 ms - -

[dmarkow]

Added some debugging to devServer2.ts. Two saves in a short time result in rebuild hashes of eab47cee and 2646d08d. Ultimately, by the time the server process restarts, it's only serving the second build. However, the loop in waitForAppServer is still waiting for the server to return the build hash. Maybe the dev server process needs a way to cancel the waitForAppServer loop when a new build happens?

Remix server listening on port 3000 development
💿 File changed: app/routes/#.tsx
💿 Rebuilding...
💿 File changed: app/routes/#.tsx
💿 Rebuilding...
💿 Rebuilt in 2.8s
💿 Waiting for http://192.168.1.111:3000...
Waiting for app server with hash:  eab47cee
Restarting 'server.js'
💿 Rebuilt in 2.2s
💿 Waiting for http://192.168.1.111:3000...
Waiting for app server with hash:  2646d08d
Restarting 'server.js'
Remix server listening on port 3000 development
GET /__REMIX_ASSETS_MANIFEST 200 4.388 ms - -
GET /__REMIX_ASSETS_MANIFEST 200 2.450 ms - -
Expected:  2646d08d Got:  2646d08d ; returning
💿 http://192.168.1.111:3000 ready in 1.2s
Expected:  eab47cee Got:  2646d08d
GET /__REMIX_ASSETS_MANIFEST 200 2.923 ms - -
Expected:  eab47cee Got:  2646d08d
GET /__REMIX_ASSETS_MANIFEST 200 3.577 ms - -
Expected:  eab47cee Got:  2646d08d
GET /__REMIX_ASSETS_MANIFEST 200 3.937 ms - -
Expected:  eab47cee Got:  2646d08d

[arnaudambro]

I have the same problem with Express Server

[ghost]

I'm having the same problem with the new Remix Dev Server

[zelkibuilds]

Currently getting this problem as soon as our dev server is launched.

[jrestall]

Getting same problem with Express unstable_dev server. Laptop is very slow so that might be contributing to multiple builds not finishing before further edits are made.

[pcattori]

Obsoleted by #6133