ironcorelabs / futurejs Goto Github PK

GitHub is reporting a high severity vulnerability CVE2019-10747 in set-value.

By default, our Future library exists errors to be Error instances. In a number of places we use our own custom error type, so we should allow users to define this custom error type as part of the Future constructor.

I love this library!

I was wondering if y'all were open to an API addition to support Objects with Future.all(<array>)?

Similar to the .all() function in my FP library: https://www.fpromises.io/#fp-all

Thanks @madison-kerndt for kindly sharing this with me!

Known high severity security vulnerability detected in handlebars < 4.0.14 defined in yarn.lock.

yarn.lock update suggested: handlebars ~> 4.0.14.

Known high severity security vulnerability detected in js-yaml < 3.13.1 defined in yarn.lock.

yarn.lock update suggested: js-yaml ~> 3.13.1.

This is pretty edge case and strange behavior. This was discovered while using the library where the Future in question changed test state. When an assertion in the .engage on that future failed, it caused the handleWith code of the already engaged Future to be called again, which cause the map to be called again, which then blew up because the state had already changed. I pushed a minimal reproduction of the bug on the branch handle-called-out-of-scope.

test("does not get run if engages above this scope throw", (done) => {
            let mapCalledTimes = 0;
            let handleWithCalledTimes = 0;
            const action = Future.of(33)
                .handleWith((e) => {
                    console.log(`failed an infallible future: ${e}`);
                    handleWithCalledTimes++;
                    return Future.of(-1);
                })
                .map((r) => {
                    mapCalledTimes++;
                    return r;
                });

            try {
                action.engage(
                    (e) => {
                        throw e;
                    },
                    (r) => {
                        throw new Error(`oh no, something went wrong after the future has run to completion on ${r}`);
                    }
                );
            } catch (e) {
                expect(handleWithCalledTimes).toBe(0);
                expect(mapCalledTimes).toBe(1);
                done();
            }
        });

That's the test entirely though. The error thrown in the .engage causes the whole chain of the Future the engage was called on to run when it's somehow caught by the handleWith. The same thing happens if you start with a rejected Future, though then everything in the chain is run twice including the handleWith.