Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    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?