Related to #182, this error also popped up from the ct-node-client grunt task on sparky.
For me, I'm interested in why this would break the process. How aren't we handling this rejection? We wrap the entire browser launch/load/cleanup code in a try catch, so perhaps we don't have control over this. The stack doesn't give us much, but if things continue, we will want to take note here.
This one was from a puppeteer client:
71|ct-node | You have triggered an unhandledRejection, you may have forgotten to catch a Promise rejection:
71|ct-node | Error: Request failed with status code 502
71|ct-node | at createError (/data/share/phet/continuous-testing/ct-node-client/aqua/node_modules/axios/lib/core/createError.js:16:15)
71|ct-node | at settle (/data/share/phet/continuous-testing/ct-node-client/aqua/node_modules/axios/lib/core/settle.js:17:12)
71|ct-node | at IncomingMessage.handleStreamEnd (/data/share/phet/continuous-testing/ct-node-client/aqua/node_modules/axios/lib/adapters/http.js:322:11)
71|ct-node | at IncomingMessage.emit (node:events:525:35)
71|ct-node | at endReadableNT (node:internal/streams/readable:1359:12)
71|ct-node | at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
This one was from a firefox client:
48|ct-node | You have triggered an unhandledRejection, you may have forgotten to catch a Promise rejection:
48|ct-node | Error: Request failed with status code 414
48|ct-node | at createError (/data/share/phet/continuous-testing/ct-node-client/aqua/node_modules/axios/lib/core/createError.js:16:15)
48|ct-node | at settle (/data/share/phet/continuous-testing/ct-node-client/aqua/node_modules/axios/lib/core/settle.js:17:12)
48|ct-node | at IncomingMessage.handleStreamEnd (/data/share/phet/continuous-testing/ct-node-client/aqua/node_modules/axios/lib/adapters/http.js:322:11)
48|ct-node | at IncomingMessage.emit (node:events:525:35)
48|ct-node | at endReadableNT (node:internal/streams/readable:1359:12)
48|ct-node | at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
Related to #182, this error also popped up from the ct-node-client grunt task on sparky.
For me, I'm interested in why this would break the process. How aren't we handling this rejection? We wrap the entire browser launch/load/cleanup code in a try catch, so perhaps we don't have control over this. The stack doesn't give us much, but if things continue, we will want to take note here.
This one was from a puppeteer client:
This one was from a firefox client: