fs methods returning an additional, undefined value in callback

[jacobheun]

• Version: 10.1.0
• Platform: Darwin 17.5.0 Darwin Kernel Version 17.5.0: Fri Apr 13 19:32:32 PDT 2018; root:xnu-4570.51.2~1/RELEASE_X86_64 x86_64
• Subsystem: fs

In node 10, fs callbacks are returning an extra undefined value. This violates the current api.

The following code

const fs = require('fs');
function callback() {
  console.log(arguments);
}
fs.unlink('/tmp/existing-file.txt', callback)

will output: [Arguments] { '0': null, '1': undefined }

The expected output should be [Arguments] { '0': null }, which it is in node 8.

This creates problems for libraries such as async that expect the signature of fs to only return the error in the callback. fs.unlink is listed above but I have seen the behavior in other methods, such as fs.link.

Sample async code this causes issues with:

const waterfall = require('async/waterfall')
waterfall([
  (callback) => fs.unlink('/tmp/existing-file.txt', callback),
  (callback) => {
    ...
    // Callback is undefined here because "undefined" is being passed into the `unlink` callback along with a null error
    callback()
  }
])

In order to mitigate the issue the above code would have to change

(callback) => fs.unlink('/tmp/existing-file.txt', callback),

to

(callback) => fs.unlink('/tmp/existing-file.txt', err => callback(err)),

[Trott]

This appears fixed on the current master branch, so it might be something that is also fixed in the next Node.js release. I'll see if I can figure out what commit changed the behavior back to the expected behavior and then see if it is slated for the next release or not. Uh, unless someone else beats me to it.

[richardlau]

Duplicate of #20335 fixed by #20629.

[Trott]

The fix for this issue is likely to be included in 10.2.0 but if not that release, then certainly the next release after that.