Open saeho opened 4 days ago
What are the steps needed to reproduce the error on our machines?
What are the steps needed to reproduce the error on our machines?
Before that, I would really like to know how I can disable initial browser refresh (NOT hot code refreshes) in dev.ts so I can deploy dev.ts and see the error in non-minified version.
Steps to reproduce:
More tests have allowed me to deduce that this is caused by Signals, possibly global constant signals, but might be duplicatable using useSignal() too.
I need to see the error in non-minified form to get more info, but dev.ts makes that impossible with initial browser refresh.
Edit: Further tests allowed me to duplicate the error using useSignal() without anything global in a minimal codebase (same repo above)
Before that, I would really like to know how I can disable initial browser refresh (NOT hot code refreshes) in dev.ts so I can deploy dev.ts and see the error in non-minified version.
Just a drive-by suggestion, but is your issue that the devtools console is getting cleared because of the refresh? Both FireFox and Chrome (and I'd imagine Safari too) have an option in the devtools to persist logs which you can enable to get around this.
Before that, I would really like to know how I can disable initial browser refresh (NOT hot code refreshes) in dev.ts so I can deploy dev.ts and see the error in non-minified version.
Just a drive-by suggestion, but is your issue that the devtools console is getting cleared because of the refresh? Both FireFox and Chrome (and I'd imagine Safari too) have an option in the devtools to persist logs which you can enable to get around this.
Thank you, I can't believe I didn't know about this option before.
Well, after looking into it it's a default "WebSocket connection to _frsh/alive failed" which is normal since the old fresh app died.
In development, this isn't an issue because the app is force refreshed by dev script. But in production this is an issue because the app does not force refresh, causing existing users to be stranded.
I actually think this is a Signal related issue because I was able to reproduce it with minimal code base in the repo I attached above.
Reproduced without PM2, using a single line of code.
More info/discussion in this PreactJS Signal thread: https://github.com/preactjs/signals/issues/581
https://github.com/denoland/fresh/assets/9645145/b9b99264-561e-441e-94dd-4b9dacb23f9b
Related issue & better video: https://github.com/denoland/fresh/issues/2564
In this video, the app works. Half way through the video, I ran a command in terminal like this:
deno task build && pm2 start main.ts --name=\"APP NAME\" --interpreter=\"deno\" --interpreter-args=\"run -A main.ts\" && pm2 save
basically using PM2 to servemain.ts
. That's when the app crashes.Able to duplicate 100% by deploying a new build using PM2 to serve
main.ts
.Cannot duplicate if deploying a new build WITHOUT PM2 to serve
main.ts
manually.I cannot read deduce if this error is coming from Fresh, or a Socket.io or possibly my code, but reading the production minified code, I don't think it's my code. I could be wrong though.
I'd like to investigate this error more by deploying using PM2. the
dev.ts
file instead. But I can't, because serving dev.ts causes the browser to refresh on reconnect to $fresh. So I need some way to disable initial app refresh when dev.ts runs.If someone understands why PM2 causes Deno Fresh to break, I'd like some input.
Update: This issue is not tied to PM2, serving the app without PM2 is equally a severe problem.