Open marcel-se-best opened 3 years ago
Also encountered this issue recently this morning. I am using MERN on my project. I tried deploying a new project with same packages and still receives the same error.
Steps to Reproduce
import * as express from "express"
import * as cors from "cors"
import * as mongoose from "mongoose"
const app = express()
const port = 5000;
app.use(cors())
app.use(express.json())
const uri = <Connection String>;
(async() => {
try {
await mongoose.connect(uri, {
useNewUrlParser: true,
useCreateIndex: true,
reconnectTries: 2,
reconnectInterval: 500
})
} catch(error) {
console.error(`Error connecting to database: ${error}`)
}
})()
const connection = mongoose.connection
connection.once('open', () => {
console.log(`MongoDB database connection established successfully.`)
})
app.listen(port, () => {
console.log(`Server is running in port: ${port}`);
})
nodemon server.ts
Expected Result Will able to run the server for a long time without any error
Actual Result Returns error:
Error: read ECONNRESET
at TLSWrap.onStreamRead (internal/stream_base_commons.js:209:20)
Perfectly accurate but unhelpful advice from another thread about ECONNRESET:
ECONNRESET means the peer closed the connection (i.e., a fact of life you simply need to deal with) and should be handled by adding 'error' event listeners in the right places.
The real issue here isn't the ECONNRESET. It's the fact that the error object does not contains enough information to identify the "right places" to add the needed listeners.
For example, this is the entire call stack for the one that periodically restarts my service:
Error: read ECONNRESET
at TLSWrap.onStreamRead (node:internal/stream_base_commons:217:20)
at TLSWrap.callbackTrampoline (node:internal/async_hooks:130:17)
I suspect that those worthless call stacks are not a nodejs problem, but rather a Javascript runtime problem. But whether or not that's the case, could nodejs do anything to make these call stacks useful?
For example, provide default error listeners that just log information about which listener caught the error before terminating the process. That would give us enough information to actually use the advice that I quoted above.
What steps will reproduce the bug?
Implement castv2-client as in the example.
On Internet-Router (Fritzbox 7490) configure a port forwarding. Expose the whole Host (Google-Cast-Device).
Try to cast to the device via the public IP.
Connection fails, with the following error: Error: read ECONNRESET at TLSWrap.onStreamRead (node:internal/stream_base_commons:213:20) { errno: -54, code: 'ECONNRESET', syscall: 'read' }
Casting to the device by local IP is working.
How often does it reproduce? Is there a required condition?
always
What is the expected behavior?
Cast-Device is playing
Additional information
Casting to the device by local IP is working.