Node fs rmdir TypeError 'Callback must be a function' - node.js

When using the fs.rmdir function I get this error from Ubuntu:
fs.js:136
throw new ERR_INVALID_CALLBACK();
^
TypeError [ERR_INVALID_CALLBACK]: Callback must be a function
at makeCallback (fs.js:136:11)
at Object.rmdir (fs.js:671:14)
<...>
I'm not sure what the cause of this is, since it works perfectly fine when I test it locally on my Windows 10 computer.
Here's the code that is causing the error:
// remove client's temporary directory and its files
fs.rmdir('temp/' + socketID, {recursive: true}, (error) => {
if(error) throw error;
});
Also, on the Ubuntu machine, if I remove the {recursive: true} option, the command does run and the callback works, but it doesn't solve the problem since I want the recursive option.

You are apparently running an older version of nodejs on that machine where it doesn't work that does not support the 2nd argument for options and thus it thinks you're passing the options object in the place where it expects the callback.
Check your nodejs version. You will need at least v12.10 to get support for the recursive option. Based on the error you report, it looks like you have a version of v10 or greater, but less than v12.10. Update your nodejs installation and you should be good.
Here's the development history for fs.rmdir():
v13.3.0, v12.16.0
The maxBusyTries option is renamed to maxRetries, and its default is 0.
The emfileWait option has been removed, and EMFILE errors use the same retry logic as
other errors. The retryDelay option is now supported. ENFILE errors are now retried.
v12.10.0
The recursive, maxBusyTries, and emfileWait options are now supported.
v10.0.0
The callback parameter is no longer optional. Not passing it will throw a TypeError
at runtime.
v7.6.0
The path parameters can be a WHATWG URL object using file: protocol. Support is currently
still experimental.
v7.0.0
The callback parameter is no longer optional. Not passing it will emit a deprecation
warning with id DEP0013.
v0.0.2
Added in: v0.0.2

Related

How do you export an object in a module in nodejs?

There is something wrong with the way I understand how to use classes in a Javascript module and export them, or some bad assumption I made about how nodejs works. Please help me understand this better. I wanted to write a module that exposed an object that will "store things safely." I have a file ("safestore.js") with this in it:
class Safestore {
constructor() {
console.log("SUCCESS!");
}
... // I defined other methods here...
}
exports.safestore = Safestore; // I tried this with `new Safestore` and `new Safestore()` too.
I run nodejs on my command line and then:
> ss = require('./safestore');
{ safestore: [Function] }
> s = ss.safestore('pwd','./encFile.enc');
ReferenceError: Safestore is not defined...
Why is it telling me that Safestore is not defined while executing the safestore function which is defined in the same file where Safestore is, actually defined?
The question does not contain enough information, although there is a clue. node and nodejs are two different pieces of software, and I was using the wrong one. I also didn't specify what version of nodejs I ran from my command line. When I ran it with node (instead of nodejs) I got errors that made sense and I was able to fix them.
Thanks to #Ethicist for listing the version of Node he used, as this got me to double check all those things.
I just need to remember that node and nodejs each do different things. Further research shows me that nodejs is a symlink to version 8.10.0 of node.js, and node is a symlink to the version that I set with nvm. I solved the problem permanently for myself with sudo rm /user/bin/nodejs and I'll remember, if I ever see an error that says nodejs doesn't exist, that it wants the old version of node.js.

Firebase functions throws uncatchable error

I'm calling the following Firebase function:
exports.getUserRecord = functions.https.onCall(async (data, context) => {
try {
//This successfully logs an existing uid in firestore, it should be retrievable
console.log(context.auth.uid)
const doc = admin.firestore().collection('user').doc(context.auth.uid);
const res = await doc.get() //Isolated it down to this line that is failing
return res
} catch (err) {
console.log(err)
throw new functions.https.HttpsError('unavailable', 'some error message');
}
});
When calling this function I receive the following error on the client:
POST https://us-central1-xxx-xxx.cloudfunctions.net/getUserRecord 500
Uncaught (in promise) Error: INTERNAL
On the server logs I see this error:
Unhandled error function error(...args) {
write(entryFromArgs('ERROR', args));
}
I am wondering how there is an error that neither of my error logging lines are picking up, and also what is causing this error?
EDIT: I have also tried logging other things within my catch block but they do not appear, it seems there is an error but the code does not enter the catch block somehow.
I have also seen this post which seems to suggest this was an issue that was patched in firebase-functions 3.9.1, but I have upgraded and still have this issue
Walked through the firebase-functions code for onCall at v3.11.0 and I don't see any other issues that could relate to this in the code since the fix
https://github.com/firebase/firebase-functions/issues/757
After discussing with #Matt about node_module versions we found that the issue is related to node_modules not having updated to latest once the upgrade was initially done.
Notes for anyone running into this issue in the future
If updating to latest for this module make sure to do the following to cover all bases,
Look into node_modules/firebase-functions/package.json attribute version to make sure that the proper version is installed.
Also take a look at your root folder package.json and package-lock.json to makes sure the proper versions are the latest.
If anything is not at version v3.9.1 or higher, then do the following,
rm -rf node_modules
npm i firebase-functions#latest --save
After that, double check everything again to make sure all is good.

GCP Secret Manager throws: "path" argument must be of type string

I'm working on using the GCP Secrets Manager from Node.js 8.x (I know, it's ancient, but it's the newest GA Node runtime on Cloud Functions). However, when I run their example, it keeps throwing gRPC error from this line:
TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type object
Line of code I'm trying to test:
const secretClient = new SecretManagerServiceClient();
I get the same error if I'm running on Node 8.x or Node 10.x, and if I use the latest version of the secrets lib (3.0.0) or the legacy version for Node 8.x (1.2.1)
It appears this error occurred because the library is running browser rather than Node mode, which forces it to avoid "fallback" mode, trying to lookup the gRPC path incorrectly. The decision is because window is in scope, tricking the isBrowser logic.
Root Cause
The root cause is that jest was used to test, which by default runs in jsDom mode, inserting globals like window.
Fix
Add the following to your jest.config.json file.
testEnvironment: 'node',

Expect assertions type error -> expect(...).toExist is not a function

I'm testing a NodeJS app. I encountered this error when I ran the tests. The test script is below:
.expect((res) => {
expect(res.headers['x-auth']).toExist();
expect(res.body._id).toExist();
expect(res.body.email).toBe(email);
})
The error showed:
TypeError: expect(...).toExist is not a function
How can I resolve this issue?
The expect assertion library has changed ownership. It was handed over to the Jest team, who in their infinite wisdom, created a new API.
You must now use toBeTruthy()instead of toExist().
You can still install expect as before, npm install expect --save-dev, which is currently at version 21.2.1. Most methods names will remain unchanged except for a few, including toExist().
If you are using Jest you can also use 'toBeDefined()'

Can't run redis-node-client test code

I downloaded node.js (.3), redis (2.0.4), and redis-node-client (git clone). When I start the redis server in one window, then go to the node-client folder and run
node test/test.js
I get
........................................
node.js:66
throw e; // process.nextTick error, or 'error' event on first tick
^
Maximum call stack size exceeded
I'm using the default configs at the moment. Haven't changed anything. Any ideas?
Hm, turns out to be version incompatibilities. Going to v0.2.5 fixes it.
Edit: nevermind, no it doesn't. Comes up with new error:
AssertionError: "testZINTER" "ERR unknown command 'zinter'"
at /Users/vhwanger/Dropbox/Programming/nodejs/redis-node-client/test/test.js:121:25
at Client.onReply_ (/Users/vhwanger/Dropbox/Programming/nodejs/redis-node-client/lib/redis-client.js:400:34)
at /Users/vhwanger/Dropbox/Programming/nodejs/redis-node-client/lib/redis-client.js:143:30
at ReplyParser.feed (/Users/vhwanger/Dropbox/Programming/nodejs/redis-node-client/lib/redis-client.js:160:55)
at Stream.<anonymous> (/Users/vhwanger/Dropbox/Programming/nodejs/redis-node-client/lib/redis-client.js:337:28)
at Stream.emit (events:27:15)
at IOWatcher.callback (net:489:16)
at node.js:773:9
Sadly, redis-node-client is no longer maintained. That's why I've written node_redis, which you can get with:
npm install redis
There are a lot of people using it now, and this has helped us work out a lot of bugs. Let me know if you have any issues with it.

Resources