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
When logging requests sent to http imposters defined with recordRequests=true, Mountebank occasionally writes an empty request file, with size 0 bytes, to the filesystem. This leads to later unhandled promise exception errors, which occur when a GET is done on the same imposter, and this unhandled promise exception causes a crash of the application.
So it would appear that there are two problems which need to be tackled:
Bug causing the file to be written to the filesystem as zero bytes
Bug causing mountebank to crash when it encounters a zero-byte empty json file, when parsing request files.
Expected behaviour
Mountebank writes a complete request file to disk for incoming requests to http imposter.
Mountebank responds successfully to GET requests for the imposter, without crashing.
Actual behaviour
Mountebank writes an empty, 0-byte request file to disk.
Mountebank crashes upon encountering an empty when responding to a GET request on the imposter, logging the following unhandled promise exception:
[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "Error: invalid JSON in /mountebank/data/4210/requests/1714862649260-1-2.json".] {
code: 'ERR_UNHANDLED_REJECTION'
}
Suggested Behaviour
When listing the requests, return a json block to indicate that an empty request file exists rather than simply skipping over any parse errors.
Steps to reproduce
This could be tricky to replicate as you'd need to first understand what makes mountebank create the empty request file, and I'm not sure how to provoke mountebank to do this on demand. It might have something to do with malformed requests, like the kind of request a vulnerability scanner like nessus may routinely create during a vulnerability scan etc.
Create an imposter of type http with recordRequests=true, then send requests to it - our request logs volume was around 15k.
Software versions used
Docker image: bbyars/mountebank:2.9.1
OS : N/A
mountebank : 2.9.1
node.js : N/A
(only if installed via npm)
Installation method :
(npm, zip, tar, pkg, deb, rpm)
Log contents in mb.log when running mb --loglevel debug
[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "Error: invalid JSON in /mountebank/data/4210/requests/1714862649260-1-2.json".] {
code: 'ERR_UNHANDLED_REJECTION'
}
The text was updated successfully, but these errors were encountered:
When logging requests sent to http imposters defined with recordRequests=true, Mountebank occasionally writes an empty request file, with size 0 bytes, to the filesystem. This leads to later unhandled promise exception errors, which occur when a GET is done on the same imposter, and this unhandled promise exception causes a crash of the application.
So it would appear that there are two problems which need to be tackled:
Expected behaviour
Actual behaviour
Suggested Behaviour
When listing the requests, return a json block to indicate that an empty request file exists rather than simply skipping over any parse errors.
Steps to reproduce
This could be tricky to replicate as you'd need to first understand what makes mountebank create the empty request file, and I'm not sure how to provoke mountebank to do this on demand. It might have something to do with malformed requests, like the kind of request a vulnerability scanner like nessus may routinely create during a vulnerability scan etc.
Create an imposter of type http with recordRequests=true, then send requests to it - our request logs volume was around 15k.
Software versions used
Log contents in mb.log when running mb --loglevel debug
The text was updated successfully, but these errors were encountered: