expressjs/express

Sinatra inspired web development framework for node.js -- insanely fast, flexible, and simple

Copot Matei

@towc

well, destroy triggers it, but a try/catch around it shows nothing

I get the error between 1 and 10 times (10 being my max pool size. Not sure if a coincidence or not) every test run

pg_stat_activity is clean

and I've just noticed these errors started to pop up, after some more test runs:

Unhandled rejection Error: Unable to acquire a connection
    at Client_PG.acquireConnection (/app/node_modules/knex/lib/client.js:342:30)
    at Runner.ensureConnection (/app/node_modules/knex/lib/runner.js:245:8)
    at Runner.run (/app/node_modules/knex/lib/runner.js:25:27)
    at Builder.Target.then (/app/node_modules/knex/lib/interface.js:14:43)
    at Builder.tryCatcher (/app/node_modules/bluebird/js/release/util.js:16:23)
    at doThenable (/app/node_modules/bluebird/js/release/thenables.js:63:38)
    at tryConvertToPromise (/app/node_modules/bluebird/js/release/thenables.js:28:20)
    at Promise._resolveCallback (/app/node_modules/bluebird/js/release/promise.js:465:24)
    at Promise._settlePromiseFromHandler (/app/node_modules/bluebird/js/release/promise.js:559:17)
    at Promise._settlePromise (/app/node_modules/bluebird/js/release/promise.js:604:18)
    at Promise._settlePromiseCtx (/app/node_modules/bluebird/js/release/promise.js:641:10)
    at _drainQueueStep (/app/node_modules/bluebird/js/release/async.js:97:12)
    at _drainQueue (/app/node_modules/bluebird/js/release/async.js:86:9)
    at Async._drainQueues (/app/node_modules/bluebird/js/release/async.js:102:5)
    at Immediate.Async.drainQueues [as _onImmediate] (/app/node_modules/bluebird/js/release/async.js:15:14)
    at processImmediate (internal/timers.js:439:21)

Copot Matei

@towc

this last error starts happening continuously, without re-running tests

every 10 seconds or so, a batch of them comes (unreliably)

I have a strong feeling this is because of the knex store, as knex wouldn't automatically attempt to reconnect, right?

I'll just try a different store

witha memory store, none of those errors appear (I still have knex.destroy())

Copot Matei

@towc

connect-pg-simple looked promising, and I might keep going that way, although there seem to be some major issues. The sequelize/fortune stores haven't been updated in over a year, which is worrying

I'm considering an efficient memory store now: https://www.npmjs.com/package/memorystore

yup, seems to work fine :) and pg activity isn't growing after retests anymore :D

thanks

Maxim Orlov

@Maximization

glad you found a solution! seems knex and mocha --watch don't play nice together

be aware that memory store is flushed at app restart and might be a source of memory leak in production

Copot Matei

@towc

the one in the package claims not to be leaky, but that it keeps everything in memory

which is interesting because that doesn't make sense to me. Any "database" that keeps things in memory is leaky, right?

or does leaky only apply to keeping unaccessible/non-useful information in memory?

Copot Matei

@towc

another issue is that I should have used afterEach rather than after. Woops.

Maxim Orlov

@Maximization

Indeed. The difference between the two is that this lib removes stale/expired sessions and you can configure some things like max memory size and prune intervals. Not sure how it handles storing new sessions when max size is reached and there's nothing left to prune ¯_(ツ)_/¯

or does leaky only apply to keeping unaccessible/non-useful information in memory?

Yeah I guess by that definition it's not a memory leak when you actually need to access the data at some point in the future. Still the two major points remain that store is wiped on restart and might eat up server RAM

Copot Matei

@towc

it would be neat if I could just try { next() } catch (e) { res.status(500).json({ error: 'internal' }) } in a middleware

from what I understand, I'm meant to use a middleware with 4 arguments, although it's not working. Very likely an issue on my side. But it would be neat if that try/catch worked

the scenario is that a middleware after it has throw new Error(...). But it is in an async function and so on, which might be an issue. try { await next() } doesn't help

Copot Matei

@towc

wrapping every single async handler I have with try/catch so I can call next(err) sounds like a horrible way to solve this :/

unless express provides some other neat mechanism, I might need to implement my own middleware engine. Which I've done in other projects, but this time I thought I'd try doing it as close to intended as possible

Maxim Orlov

@Maximization

Ah yeah, awaiting next() won't work. Having an error middleware at the end is how it's usually done. You have to pass an argument to next for it to be called next(err). More about it here https://expressjs.com/en/guide/error-handling.html

I remember someone coming with a nifty approach to this, let me see if I can find it

Copot Matei

@towc

if I used babel, I could have a decorator do the async try/catch wrapping for me

Maxim Orlov

@Maximization

This might give you an idea of a way to approach this

function catchErrors(fn) {
  return function (req, res, next) {
    return fn(req, res, next).catch(next);
  };
};

router.get('/', catchErrors(/* your middleware function */));

Copot Matei

@towc

yup, acting as a decorator

I'd feel much more comfortable writing @catchErrors in the line above the async definition than inserting more parens in my code

Copot Matei

@towc

custom middleware engine it is, at least to allow to iterate over all middleware/controllers so I can wrap in a function

Ruben Rutten

@Cyberuben

Hi, I have two questions. I've got a middleware function that uses req.route.path to validate some information. Right now, I need to define all my routes like router.get("/path/of/my/route/:someParameter", myMiddlewareFunction, (req, res) => { /* actual route handler */ }); Is there a way for me to avoid having to do this?

The 2nd question I have is somewhat related, I want to write a request logger AFTER the request has taken place so that I can insert the time it took to process the request and the HTTP status code into a database, but I would like to also store the req.route.path in the database. Have you got any suggestions on how to achieve this?

Copot Matei

@towc

@Cyberuben you mean you have to do it because path only refers to the path within the outer router? You can join it with req.baseUrl to get the full path, within an express.Router()

Ruben Rutten

@Cyberuben

@towc the problem with that though is that it substitutes the route params, and I specifically want the route params to be there.

To give you some more background, I'm using JSON schemas for validation of query, params and body. So upon receiving a request, I'm using req.route.path that'll output something like /some/route/with/:param and that'll validate the request against a JSON schema with the name requests/GET/some/route/with/_param. I have this part working perfectly fine, it's just that I want to avoid having to manually include the middleware in every controller

Copot Matei

@towc

My experience with express doesn't go beyond the basics, but if you need some custom stuff, it could be beneficial to write your own route builder, so you can use app.get on the full path without routers

for example

const routes = {
  use: [s.wrapErrors, v.knexConnected],
  '/auth': {
    'post /login': [v.user.notLoggedIn, v.user.login, c.user.login],
    'post /signup': [v.user.notLoggedIn, v.user.login, v.user.noSignupConflicts, c.user.createAndLogin],
    'get /logout': [s.user.login, c.user.logout],
  },
  ...

Ruben Rutten

@Cyberuben

Fair enough, I'll look into it, thank you

Ruben Rutten

@Cyberuben

@towc I'm using InversifyJS together with inversify-express-utils and I overrode their HTTP decorators to include my middleware.

export function all(path: string, ...middleware: interfaces.Middleware[]): interfaces.HandlerDecorator {
    middleware.unshift(TYPES.ValidateRequestMiddleware);

    // @ts-ignore
    return httpMethod.apply(void 0, ["all", path].concat(middleware));
}

Copot Matei

@towc

oh, that works

Kevin López Brante

@kddlb

Hey all, how do I set a cookie in a router-level middleware function? I'm trying to handle OAuth2 token expiry and refreshing

And doing res.cookie seems to do nothing.

Kevin López Brante

@kddlb

Hm... apparently setting the cookie on its own doesn't work

I had to do res.cookie[...]..redirect(req.path) as a workaround :/

Copot Matei

@towc

you could set a temporary cookie (like res.tempCookie), and then set it in the controllers, using res.tempCookie

Eugene Serkin

@jeserkin

@dougwilson, regarding issue, that was closed and topic, that I tried to reference. Where does expressjs take and populate cookies from? How can one access headers?

Anuj Bansal

@ab63

Is there some way I can have a render and redirect in the same endpoint?

Where communities thrive

People

Repo info

Activity