You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've recently started noticing some unhandled promise rejections that are being thrown by discv5.sendPing inside of Ultralight. The stack trace for the error looks like below:
atcallback(file:///home/jim/development/ultralight/node_modules/@chainsafe/discv5/lib/service/service.js:354:33)atSessionService.rpcFailure(file:///home/jim/development/ultralight/node_modules/@chainsafe/discv5/lib/service/service.js:811:13)atSessionService.emit(node:events:514:28)atSessionService.failRequest(file:///home/jim/development/ultralight/node_modules/@chainsafe/discv5/lib/session/service.js:650:14)atSessionService.handleRequestTimeout(file:///home/jim/development/ultralight/node_modules/@chainsafe/discv5/lib/session/service.js:615:18)atTimeoutMap.onTimeout(file:///home/jim/development/ultralight/node_modules/@chainsafe/discv5/lib/session/service.js:98:84)atTimeout.<anonymous> (file:///home/jim/development/ultralight/node_modules/@chainsafe/discv5/lib/util/timeoutMap.js:25:22)
at listOnTimeout (node:internal/timers:569:17)
at process.processTimers (node:internal/timers:512:7)
I looked through the calls to sendPing in the discv5 codebase and it doesn't look like any of them are directly wrapped in try/catch blocks so not sure where I need to look to see why this isn't being handled since it looks like it's a basic session timeout issue (which shouldn't be a critical requiring a consuming application to handle it.
Since we never call discv5.sendPing directly inside Ultralight, I'm trying to determine if this is some new issue that has cropped up with discv5 or if it's something Ultralight did (or didn't) do with regard to properly guarding network calls with our discv5 client.
Any suggestions?
For our part, we're temporarily employing a process.on('uncaughtException... handler to keep Ultralight from crashing for now since as best I can tell this comes from trying to ping unreachable nodes and the rejections just not being handled properly.
The text was updated successfully, but these errors were encountered:
We've recently started noticing some unhandled promise rejections that are being thrown by
discv5.sendPing
inside of Ultralight. The stack trace for the error looks like below:and the debugger links the source of the error to this promise rejection in
sendPing
.I looked through the calls to
sendPing
in the discv5 codebase and it doesn't look like any of them are directly wrapped intry
/catch
blocks so not sure where I need to look to see why this isn't being handled since it looks like it's a basic session timeout issue (which shouldn't be a critical requiring a consuming application to handle it.Since we never call
discv5.sendPing
directly inside Ultralight, I'm trying to determine if this is some new issue that has cropped up withdiscv5
or if it's something Ultralight did (or didn't) do with regard to properly guarding network calls with ourdiscv5
client.Any suggestions?
For our part, we're temporarily employing a
process.on('uncaughtException...
handler to keep Ultralight from crashing for now since as best I can tell this comes from trying to ping unreachable nodes and the rejections just not being handled properly.The text was updated successfully, but these errors were encountered: