JavaScript ES6 - console.log with template literal - javascript

I'm writing node's script that connect to the mongo database.
I noticed that printing error response is different by small change in console.log syntax. Below example should be more meaningful.
#!/usr/bin/env node
const mongoose = require("mongoose");
const config = require("./config");
mongoose.connect(config.dbURI, (err) => {
if (err) {
console.log(`${err}`); // First console.log
console.log(err); // Second console.log
} else {
console.log(`Database connection successful`)
}
});
Example output of the first console.log
MongoError: Authentication failed.
Example output of the second console.log
{ MongoError: Authentication failed.
at Function.MongoError.create (/Users/sigo/Sources/crypto-change/node_modules/mongodb-core/lib/error.js:31:11)
at /Users/sigo/Sources/crypto-change/node_modules/mongodb-core/lib/connection/pool.js:489:72
at authenticateStragglers (/Users/sigo/Sources/crypto-change/node_modules/mongodb-core/lib/connection/pool.js:435:16)
at Connection.messageHandler (/Users/sigo/Sources/crypto-change/node_modules/mongodb-core/lib/connection/pool.js:469:5)
at Socket.<anonymous> (/Users/sigo/Sources/crypto-change/node_modules/mongodb-core/lib/connection/connection.js:321:22)
at emitOne (events.js:96:13)
at Socket.emit (events.js:191:7)
at readableAddChunk (_stream_readable.js:178:18)
at Socket.Readable.push (_stream_readable.js:136:10)
at TCP.onread (net.js:563:20)
name: 'MongoError',
message: 'Authentication failed.',
ok: 0,
code: 18,
errmsg: 'Authentication failed.' }
Where comes from this difference?

${err} (or '' + err for that matter) will interpolate the err object with a string which will also change your Error object into a string - which is equivalent to calling err.toString(). However directly logging err will pass it to the console as an object and display it in that manner.
This is called "implicit coercion" - if you would like to know more about this subject I can highly recommend reading You Don't Know JS: Types & Grammar (Chapter 4: Coercion) for a deep dive.

By interpolating in a template string, the err object is cast to a string, using its own .toString method that is inherited from Error.prototype.toString. The code is equivalent to
console.log(String(err));
console.log(err.toString());
When passing the err object directly to the console.log method, it uses node's inspect function instead, the code is equivalent to
console.log(util.inspect(err));

Related

Getting the right stack trace out of jest

I am currently debugging some tests written with jest over typescript and I'm having a bit of a headache.
If a test, or tested class, runs Postgres SQL and there is an error in the query, I get the wrong stack trace, for example, this:
error: invalid input syntax for type integer: ""0""
at Parser.parseErrorMessage (/Users/sklivvz/src/xxx/node_modules/pg-protocol/src/parser.ts:369:69)
at Parser.handlePacket (/Users/sklivvz/src/xxx/node_modules/pg-protocol/src/parser.ts:188:21)
at Parser.parse (/Users/sklivvz/src/xxx/node_modules/pg-protocol/src/parser.ts:103:30)
at Socket.<anonymous> (/Users/sklivvz/src/xxx/node_modules/pg-protocol/src/index.ts:7:48)
at Socket.emit (node:events:365:28)
at addChunk (node:internal/streams/readable:314:12)
at readableAddChunk (node:internal/streams/readable:289:9)
at Socket.Readable.push (node:internal/streams/readable:228:10)
at TCP.onStreamRead (node:internal/stream_base_commons:190:23)
The "error" line is very useful, however, the stack trace only tells me that the error was thrown by the pg-protocol driver. I would like to know which line within my code generated the error.
I am exactly 82.7% sure that this is due to PG's query being async.
It is incredibly time-consuming having to step debug or (gasp) console.log my way to each error when it would only be a matter of showing the correct call stack in order to make it better.
Has anyone found a way of making this developer-friendly?
Check if this is related to brianc/node-postgres issue 2484
is (there) a preferred package, extension, or method for providing more detail when you get a syntax error back from the parser?
(for instance, one that listed line number, column of the error)
for instance, right now:
error: syntax error at or near "as"
at Parser.parseErrorMessage (/home/collspec/projects/staff-portal/sprint-server/node_modules/pg-protocol/dist/parser.js:278:15)
desired behavior:
error: syntax error at or near "as", line 5, column 7
at Parser.parseErrorMessage (/home/collspec/projects/staff-portal/sprint-server/node_modules/pg-protocol/dist/parser.js:278:15)
Possible workaround from that issue:
There are a bunch of additional fields on Error objects populated by the driver.
If you log the error object you can see them. They correspond to the error fields returned by the server:
For example with the command:
SELECT foo
FROM bar
You can get an error like this:
{
length: 102,
severity: 'ERROR',
code: '42P01',
detail: undefined,
hint: undefined,
position: '17',
internalPosition: undefined,
internalQuery: undefined,
where: undefined,
schema: undefined,
table: undefined,
column: undefined,
dataType: undefined,
constraint: undefined,
file: 'parse_relation.c',
line: '1180',
routine: 'parserOpenTable'
}
The one you want is position. It gives you the character offset in the SQL of the error.
In this example the position value of "17" refers to the start of the bar token in the SQL.
It's not always populated though as it depends on what caused the error (generally just parse errors).
I ran into a similar issue with aws-sdk for DynamoDb. This is a stacktrace I usually get from aws-sdk.
ResourceNotFoundException: Requested resource not found
at Request.extractError (D:\workspaces\typescript-starters\console-app\node_modules\aws-sdk\lib\protocol\json.js:52:27)
at Request.callListeners (D:\workspaces\typescript-starters\console-app\node_modules\aws-sdk\lib\sequential_executor.js:106:20)
at Request.emit (D:\workspaces\typescript-starters\console-app\node_modules\aws-sdk\lib\sequential_executor.js:78:10)
at Request.emit (D:\workspaces\typescript-starters\console-app\node_modules\aws-sdk\lib\request.js:688:14)
at Request.transition (D:\workspaces\typescript-starters\console-app\node_modules\aws-sdk\lib\request.js:22:10)
at AcceptorStateMachine.runTo (D:\workspaces\typescript-starters\console-app\node_modules\aws-sdk\lib\state_machine.js:14:12)
at D:\workspaces\typescript-starters\console-app\node_modules\aws-sdk\lib\state_machine.js:26:10
at Request.<anonymous> (D:\workspaces\typescript-starters\console-app\node_modules\aws-sdk\lib\request.js:38:9)
at Request.<anonymous> (D:\workspaces\typescript-starters\console-app\node_modules\aws-sdk\lib\request.js:690:12)
at Request.callListeners (D:\workspaces\typescript-starters\console-app\node_modules\aws-sdk\lib\sequential_executor.js:116:18)
My workaround is simply to catch async errors, and overwrite their stack traces. On the other hand, you may append Postgres stacktrace, or error message to your own errors.
async function getPersonFromDb (personId: string): Promise<DocumentClient.AttributeMap | undefined> {
const result = await documentClient.get({ // Similar to postgres.query()
TableName: 'wrong-name',
Key: { pk: personId, sk: personId }
}).promise().catch(error => {
Error.captureStackTrace(error)
throw error
})
return result.Item
}
test('Get a person from DynamoDB', async () => {
const person = await getPersonFromDb('hello')
expect(person).not.toBeUndefined()
})
// ========= new stacktrace ========
Error: Requested resource not found
at D:\workspaces\typescript-starters\console-app\test\abc.test.ts:12:13
at processTicksAndRejections (internal/process/task_queues.js:93:5)
at getPersonFromDb (D:\workspaces\typescript-starters\console-app\test\abc.test.ts:8:20)
at Object.<anonymous> (D:\workspaces\typescript-starters\console-app\test\abc.test.ts:18:20) // my code, and where my error is thrown

Ben Awad vid tutorial problemwith npx mikro-orm migration:create

I'm following the tutorial step by step, when I get to the part of run npx mikro-orm migration:create, I get this error
TypeError [ERR_INVALID_ARG_TYPE]: The "key" argument must be of type string or an instance of Buffer, TypedArray, DataView, or KeyObject. Received null
at prepareSecretKey (internal/crypto/keys.js:322:11)
at new Hmac (internal/crypto/hash.js:113:9)
at Object.createHmac (crypto.js:147:10)
at createHMAC (C:\lireddit-server\node_modules\pg\lib\sasl.js:133:17)
at Hi (C:\lireddit-server\node_modules\pg\lib\sasl.js:137:13)
at Object.continueSession (C:\lireddit-server\node_modules\pg\lib\sasl.js:32:24)
at Client._handleAuthSASLContinue (C:\lireddit-server\node_modules\pg\lib\client.js:248:10)
at Connection.emit (events.js:314:20)
at Connection.EventEmitter.emit (domain.js:483:12)
at C:\lireddit-server\node_modules\pg\lib\connection.js:109:12
at Parser.parse (C:\lireddit-server\node_modules\pg-protocol\src\parser.ts:102:9)
at Socket.<anonymous> (C:\lireddit-server\node_modules\pg-protocol\src\index.ts:7:48)
at Socket.emit (events.js:314:20)
at Socket.EventEmitter.emit (domain.js:483:12)
at addChunk (_stream_readable.js:298:12)
at readableAddChunk (_stream_readable.js:273:9)```
I can't find any solution on google, and the tut doesn't point out how to login to postgresql on the app
You are missing some configuration, most probably user or password fields. Here is related issue:
https://github.com/mikro-orm/mikro-orm/issues/866
If you do not provide them, MikroORM will pick the defaults for given driver, which is postgres user and empty password - your postgres installation apparently do not have empty password for this user.
If you are using docker to create the postgres server, this is how you can make it accept empty pws:
postgre:
image: postgres:12.4
ports:
- 5432:5432
environment:
POSTGRES_HOST_AUTH_METHOD: trust <-- here
It seems like you have not specified the password or user property of an object which you are passing inside of MikroORM.init.
This should work
export default {
entities: [Entity],
dbName: "yourDatabaseName",
type: "postgresql",
user: "yourUserName",
password: "yourPassword"
} as Parameters<typeof MikroORM.init>[0];

TypeError: res.writeHead is not a function chapter 6 Fullstack javascript development with MEAN

So I'm following along with the Full Stack Javascript development offered by Sitepoint and I've ran into a problem found within chapter 6. I've set up a basic http server which should allow incoming connections.
When I run index.js, I get a log to the console saying it is successfully running at my designated address(127.0.0.1:1337)
As soon as I try to go to that address in my browser it fails to connect and I get this error in my terminal
TypeError: Cannot read property 'toUpperCase' of undefined
at Server.<anonymous> (/Users/user/Documents/Git projects/human-resources/index.js:8:26)
at emitTwo (events.js:106:13)
at Server.emit (events.js:191:7)
at HTTPParser.parserOnIncoming [as onIncoming] (_http_server.js:543:12)
at HTTPParser.parserOnHeadersComplete (_http_common.js:105:23)
It obviously has a problem with this line
req.method = req.method.toUpperCase();
But I don't know why, I thought maybe if I comment it out it'll work, but when I do that I get a similar error to the above but this time says res.writeHead is not a function
TypeError: res.writeHead is not a function
at Server.<anonymous> (/Users/user/Documents/Git projects/human-resources/index.js:12:9)
at emitTwo (events.js:106:13)
at Server.emit (events.js:191:7)
at HTTPParser.parserOnIncoming [as onIncoming] (_http_server.js:543:12)
at HTTPParser.parserOnHeadersComplete (_http_common.js:105:23)
If anyone could offer some insight into where I or my code is going wrong that would be great my full code is listed below..
var http = require('http');
http.createServer(function (res,req) {
//A parsed url to work with in case there are parameters
var _url;
//In case the client uses lower case for methods
req.method = req.method.toUpperCase();
console.log(req.method + ' ' + req.url);
if (req.method !== 'GET') {
res.writeHead(501, {
'Content-Type': 'text/plain'
});
return res.end(req.method + ' is not implemented by this server');
}
if (_url = /^\/employees$/i.exec(req.url)) {
//return a list of employees
res.writeHead(200);
return res.end('employee list');
} else if (_url = /^\/employees\/(\d+)$/i.exec(req.url)) {
//find employee by id in the route
res.writeHead(200);
return res.end('a single employee');
} else {
//try to send the static file
res.writeHead(200);
return res.end('static file maybe');
}
}).listen(1337, '127.0.0.1');
console.log('Sever Running at http://127.0.0.1:1337/');
I have used the request and response in the http.createServer() in the wrong order, I used response then request, should be request and then response like so;
http.createServer(function (req,res) {

Using passport-steam with sails-generate-auth

I'm creating a SailsJS application, and I want users to log in only with Steam authentication. I used sails-generate-auth to create some boilerplate code with sails routes, but I'm having trouble plugging passport-steam into it.
https://github.com/kasperisager/sails-generate-auth
https://github.com/liamcurry/passport-steam
The reported error is:
C:\Users\Joe\testProject\node_modules\passport-steam\lib\passport-steam\strategy.js:67
id: result.response.players[0].steamid,
^
TypeError: Cannot read property 'steamid' of undefined
at steamapi.getPlayerSummaries.callback (C:\Users\Joe\testProject\node_modules\passport-steam\lib\passport-steam\strategy.js:67:43)
at IncomingMessage.<anonymous> (C:\Users\Joe\testProject\node_modules\passport-steam\node_modules\steam-web\lib\steam.js:218:7)
at IncomingMessage.emit (events.js:117:20)
at _stream_readable.js:944:16
at process._tickDomainCallback (node.js:486:13)
I have a feeling that this is caused by SteamWebAPI returning an empty response: {"response":{"players":[]}}, which is caused by a bogus SteamID in the request. The offending line is here in passport-steam: https://github.com/liamcurry/passport-steam/blob/master/lib/passport-steam/strategy.js#L53
Looking at identifier parameter to getUserProfile, it appears to be the entire Sails request scope. If I hardcode a good steam id into that array, I get this error:
C:\Users\Joe\testProject\api\services\passport.js:98
return next(new Error('Neither a username nor email was available'));
^
TypeError: undefined is not a function
at Authenticator.passport.connect (C:\Users\Joe\testProject\api\services\passport.js:98:12)
at module.exports (C:\Users\Joe\testProject\api\services\protocols\openid.js:24:12)
at steamapi.getPlayerSummaries.callback (C:\Users\Joe\testProject\node_modules\passport-steam\lib\passport-steam\strategy.js:72:11)
at IncomingMessage.<anonymous> (C:\Users\Joe\testProject\node_modules\passport-steam\node_modules\steam-web\lib\steam.js:218:7)
at IncomingMessage.emit (events.js:117:20)
at _stream_readable.js:944:16
at process._tickDomainCallback (node.js:486:13)
I think that makes sense since the steam response doesn't have a username nor email, but this is the profile: {"emails":[{}],"name":{}}
This is my passport configuration:
steam: {
name: 'Steam',
protocol: 'openid',
strategy: require('passport-steam').Strategy,
options: {
returnURL: 'http://localhost:1337/auth/steam/callback',
realm: 'http://localhost:1337/',
apiKey:'STEAM-API-KEY-REMOVED'
}
}
}
Not sure if there is something simple I'm missing, or I need to write a ton of custom handling. Is my configuration correct?
This is caused by out-of-date source code in npm. Even with the latest 0.1.4 version, the code is not correct. Replacing strategy.js in passport-steam with the latest version will fix this error.
Also, in api\services\passport.js, a little custom handling in passport.connect() needs to be added. The profile does not have a username, but has an id (user steamid) and displayName. These can be used to set the user model properties, e.g.
//steam auth
if (profile.hasOwnProperty('displayName')) {
user.username = profile.displayName;
}
Here is the ticket where the problem was solved: https://github.com/liamcurry/passport-steam/issues/10

Throwing exception on mongoose callback

I'm developing a Node.js + Express. My database is Mongo, and I'm using Mongoose to connect to this database.
I'm trying to throw an exception in a Mongoose query callback this way:
game.save(function (err) {
if (err) {
throw new app.exception.EntitySaveFailed();
}
});
but when I do it, Node server crashes and shows this stacktrace:
[object Object]
at Promise.<anonymous> (/home/server/routes/api/game.js:219:17)
at Promise.<anonymous> (/home/server/node_modules/mongoose/node_modules/mpromise/lib/promise.js:162:8)
at Promise.EventEmitter.emit (events.js:95:17)
at Promise.emit (/home/server/node_modules/mongoose/node_modules/mpromise/lib/promise.js:79:38)
at Promise.fulfill (/home/server/node_modules/mongoose/node_modules/mpromise/lib/promise.js:92:20)
at Promise.resolve (/home/server/node_modules/mongoose/lib/promise.js:108:15)
at Promise.<anonymous> (/home/server/node_modules/mongoose/node_modules/mpromise/lib/promise.js:162:8)
at Promise.EventEmitter.emit (events.js:95:17)
at Promise.emit (/home/server/node_modules/mongoose/node_modules/mpromise/lib/promise.js:79:38)
at Promise.fulfill (/home/server/node_modules/mongoose/node_modules/mpromise/lib/promise.js:92:20)
Forever detected script exited with code: 8
Forever restarting script for 9389 time
Listening on port 3000...
When I throw an exception outside a mongoose callback function, all works fine.
When you throw an exception in a node.js callback it goes to the code that actually invoked the callback, not the lexical scope of your code. In this case, that means the Promise library receives the exception and crashes your program. This is why errors are typically reported via the first callback parameter rather than exceptions.
You can add "next" to the params of the function, so when you need to throw an exception you can do something like this:
function saveGame(req, res, next) {
game.save(function (err) {
if (err) {
return next(new app.exception.EntitySaveFailed());
}
});
}

Categories