I'm getting an error while working through https://cloud.google.com/nodejs/getting-started/using-pub-sub. (I've successfully completed previous tutorials in the series.)
With the command "SCRIPT=worker.js PORT=8081 npm start", I get this error related to background.js:
TypeError: Cannot call method 'on' of null
at /Users/xke/Documents/node.js/6-pubsub/lib/background.js:57:20
at /Users/xke/Documents/node.js/6-pubsub/node_modules/gcloud/lib/pubsub/index.js:256:7
at /Users/xke/Documents/node.js/6-pubsub/node_modules/gcloud/lib/common/util.js:684:11
at Object.handleResp (/Users/xke/Documents/node.js/6-pubsub/node_modules/gcloud/lib/common/util.js:192:5)
at Request._callback (/Users/xke/Documents/node.js/6-pubsub/node_modules/gcloud/lib/common/util.js:679:12)
at Request.self.callback (/Users/xke/Documents/node.js/6-pubsub/node_modules/request/request.js:354:22)
at Request.EventEmitter.emit (events.js:98:17)
at Request.<anonymous> (/Users/xke/Documents/node.js/6-pubsub/node_modules/request/request.js:1207:14)
at Request.EventEmitter.emit (events.js:117:20)
at IncomingMessage.<anonymous> (/Users/xke/Documents/node.js/6-pubsub/node_modules/request/request.js:1153:12)
Thoughts / solutions?
Thanks!
It appears this is a bug in the gcloud-node library. The library is supposed to automatically create the topic for you, but it appears that there is an edge case that the topic isn't automatically created when you try to subscribe to it.
In the meantime, there is a simple way around this: run the bookshelf app and create / edit a book. It'll cause the library to create the topic. This is because the library does correctly auto-create the topic when you try to publish to it. After that, you should be able to run the worker without error.
Alternatively, you can modify background.js#subscribe to check for the topic's existence and create it if necessary.
Related
I am using Mocha with chai to perform unit testing. But I can't comprehend the error messages displayed when a test fails.
For instance, I have a simple api, that only accepts alpha characters for certain inputs. If the user attempts to submit something like "3rror", the api will return a status of 403, or some other error code.
With Mocha I can assert something like : response.should.have.status(403); to check the server is catching and serving invalid requests appropriately.
However; with Mocha, I am completely lost when trying to reason out why or what caused an error to occur. Did I write a bad test, did my sanitization/validation middleware fail, am I even connected to my server, or am I failing to handle invalid requests and/or errors appropriately?
Below is an example of an error message Mocha provides for the mentioned case.
Uncaught TypeError: Cannot read properties of undefined (reading 'should')
at C:\...\test.js:53:43
at Test.Request.callback (node_modules\chai-http\node_modules\superagent\lib\node\index.js:716:12)
at IncomingMessage.<anonymous> (node_modules\chai-http\node_modules\superagent\lib\node\index.js:916:18)
at IncomingMessage.emit (node:events:539:35)
at endReadableNT (node:internal/streams/readable:1345:12)
at processTicksAndRejections (node:internal/process/task_queues:83:21)
I understand it gave the wrong status code, but these error messages don't really help me understand what went wrong. Did I just goof an write a bad test, or did my app fail? So I am here to ask for help.
How can I better understand these errors reported when a test fails using Mocha?
I have a node webapp that makes various API calls to Stripe using the stripe npm package. Sometimes I get errors like the one below. Notice that the stacktrace is truncated so that I cannot see which stripe API call causes the error and I also cannot see where in my app this API call is made.
Is there anything I can do to get better error stacktraces?
Error: Missing required param: customer.
at Function.generate (/home/molsson/dv/foobar/node_modules/stripe/lib/Error.js:39:16)
at IncomingMessage.<anonymous> (/home/molsson/dv/foobar/node_modules/stripe/lib/StripeResource.js:175:33)
at Object.onceWrapper (events.js:299:28)
at IncomingMessage.emit (events.js:215:7)
at IncomingMessage.EventEmitter.emit (domain.js:476:20)
at endReadableNT (_stream_readable.js:1183:12)
at processTicksAndRejections (internal/process/task_queues.js:80:21)
Note: the error itself is just an example. I have already fixed it. I just want to get better stacktraces or a better method of debugging these types of errors quickly.
I'm pretty sure my node version has async stacks by default:
$ node --version
v12.12.0
$ node -p process.versions.v8
7.7.299.13-node.12
I tried running with NODE_OPTIONS='--trace-warnings --stack-trace-limit=9999' but it didn't help.
Does it exists some kind of "async stacktraces across event emitters" debugging thing?
I found a good answer to this question myself. The stripe library fires and event before making a new API request, so you can print a stacktrace from there:
stripe.on('request', request => {
const currentStack = (new Error()).stack.replace(/^Error/, '')
console.log(`Making Stripe HTTP request to ${request.path}, callsite: ${currentStack}`)
})
I added a STRIPE_API_TRACING option to my app that I can turn on if I experience errors without stacks. With the tracing on I can just scroll a bit up in the log and see what API calls was dispatched just before the error happened.
I am using application insights on my node js application and I keep on getting this error. Can you please help me
ApplicationInsights:CorrelationIdManager [ { Error: unable to verify the first certificate
at TLSSocket.<anonymous> (_tls_wrap.js:1105:38)
at ZoneDelegate.invokeTask (C:\src\xyz\xyz\xyz\node_modules\zone.js\dist\zone-node.js:275:35)
at Zone.runTask (C:\src\xyz\xyz\xyz\node_modules\zone.js\dist\zone-node.js:151:47)
at TLSSocket.ZoneTask.invoke (C:\src\xyz\xyz\xyz\node_modules\zone.js\dist\zone-node.js:345:33)
at emitNone (events.js:106:13)
at TLSSocket.emit (events.js:208:7)
at TLSSocket._finishInit (_tls_wrap.js:639:8)
at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:469:38) code: 'UNABLE_TO_VERIFY_LEAF_SIGNATURE' } ]
You're seeing this error because of transient problems on the Application Insights backend, but the error should not be fatal and your app should continue working as expected (albeit with this message being printed).
In the default configuration of the Application Insights SDK for Node.js, communication with the backend is retried - so you should be able to ignore this error and still see telemetry show up in the Azure Portal.
If you've changed the defaults, the setting you'll want to make sure to set is .setUseDiskRetryCaching(true) For example:
appInsights.setup("key")
.setUseDiskRetryCaching(true)
.start()
If you want to suppress messages like this from the SDK you can disable internal logging: (Be aware you'll be suppressing other errors potentially as well)
appInsights.setup("key")
.setUseDiskRetryCaching(true)
.setInternalLogging(false, false)
.start()
If you're curious about the history of this issue, and why it spontaneously occurs, there's a long-running issue on GitHub here: https://github.com/Microsoft/ApplicationInsights-node.js/issues/180
I used swagger (swagger.io) to built my app's API and everything works fine in production environment. However, when I ran some mocha tests on these APIs, I keep getting this error regarding status code 429 Too Many Requests:
Unhandled rejection Error: Too Many Requests
at Request.callback (..../node_modules/superagent/lib/node/index.js:698:17)
at IncomingMessage.<anonymous> (..../node_modules/superagent/lib/node/index.js:922:12)
at emitNone (events.js:91:20)
at IncomingMessage.emit (events.js:185:7)
at endReadableNT (_stream_readable.js:926:12)
at _combinedTickCallback (internal/process/next_tick.js:74:11)
at process._tickDomainCallback (internal/process/next_tick.js:122:9)
Usually this error happens after I ran the mocha test twice in a row (ie start throwing this error from the third time onwards). I suspected I was overloading my localhost server, but the error persisted even after I closed and reopened the server.
Would be super grateful if someone could point me towards the right direction to solve this problem.
Node.js version 0.10.25
AWS SDK Version latest - 2.0.23
I have an app that is continuously listening to a Queue (SQS) and if there are messages posted in that queue the app will read the message and process it and save some data to S3. When I start the app after about 20 minutes I am getting the following error continuously.
Potentially unhandled rejection [160] SignatureDoesNotMatch: Signature expired: 20141104T062952Z is now earlier than 20141104T062952Z (20141104T064452Z - 15 min.)
at Request.extractError (/myproject/node_modules/aws-sdk/lib/protocol/query.js:39:29)
at Request.callListeners (/myproject/node_modules/aws-sdk/lib/sequential_executor.js:100:18)
at Request.emit (/myproject/node_modules/aws-sdk/lib/sequential_executor.js:77:10)
at Request.emit (/myproject/node_modules/aws-sdk/lib/request.js:604:14)
at Request.transition (/myproject/node_modules/aws-sdk/lib/request.js:21:12)
at AcceptorStateMachine.runTo (/myproject/node_modules/aws-sdk/lib/state_machine.js:14:12)
at /myproject/node_modules/aws-sdk/lib/state_machine.js:26:10
at Request.<anonymous> (/myproject/node_modules/aws-sdk/lib/request.js:22:9)
at Request.<anonymous> (/myproject/node_modules/aws-sdk/lib/request.js:606:12)
at Request.callListeners (/myproject/node_modules/aws-sdk/lib/sequential_executor.js:104:18)
It is not an issue with my system time. My system time is in sync with the time of my EC2 instance. Why am I getting this error? Is it related to SQS or S3?
I know this is an old question, but I experienced it myself today.
Fortunately, and the AWS NodeJS SDK now has this configuration option called correctClockSkew, which will fix the system clock offset once an error occurs:
http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Config.html#correctClockSkew-property
It's likely the time on your computer is incorrect
The signature mismatch is because authentication process depends on clock syncronisation.
Check the time on your machine.
On Linux / WSL you can run sudo hwclock -s to fix. Other OSs will require different commands.
Thanks to Loren Segal (Amazon) for his quick response. Refer https://github.com/aws/aws-sdk-js/issues/401 for more details. In short, the SDK is not retrying signature errors for which the work around is
AWS.events.on('retry', function(resp) {
if (resp.error.code === 'SignatureDoesNotMatch') {
resp.error.retryable = true;
}
});
This is not a regression i.e, it is not a bug introduced in 2.0.23