`replyWithFile` prevents deleting folder when `persist` is used or interceptor is not hit
mbargiel opened this issue · comments
Please avoid duplicates
- I checked all open bugs and none of them matched my problem.
Reproducible test case
See description below with repro snippet.
Nock Version
13.0.4
Node Version
16.13.1
TypeScript Version
No response
What happened?
When setting up a route with replyWithFile, it eagerly opens a ReadStream on the file. If the interceptor was not hit or if the interceptor is in a scope with .persist(), it retains a lock on the file and prevents deleting the folder containing it.
The following snippet showcases the issue. Note that manually removing the interceptor does not close the file stream. I included a call to nock.removeInterceptor in the repro to prove it. (Hitting the route with a request does close the ReadStream, unless persist() was used.)
const assert = require('assert')
const fs = require('fs')
const path = require('path')
const nock = require('nock')
fs.mkdirSync('./temp')
fs.writeFileSync('./temp/file.txt', 'dummy file')
const interceptor = nock('http://example.org').get('/')
interceptor.replyWithFile(200, './temp/file.txt')
// Note: setImmediate below is necessary because Nock fails to open the ReadStream on a subsequent tick;
// that's another problem caused by opening the stream eagerly rather than on-demand
setImmediate(() => fs.rmSync('./temp', { recursive: true }))
nock.removeInterceptor(interceptor) // won't have any effect
assert(!fs.existsSync('./temp'), 'temp folder was not actually deleted')
I would expect the stream to be opened when the interceptor is hit only and/or the ReadStream to be closed when the interceptor is removed.
Would you be interested in contributing a fix?
- yes
🎉 This issue has been resolved in version 13.5.4 🎉
The release is available on:
Your semantic-release bot 📦🚀