You can't cancel a JavaScript promise (except sometimes you can)

[-]

looneysquash@reddit

Even if the garbage collector didn't behave that way, you could still decide not to resolve the promises, and you could call exit https://nodejs.org/api/process.html#processexitcode yourself when it was time to exit.

That means you do have to know when you want to call exit, instead of relying on nodejs to determine that. But it means you do still exit deterministically even if you accidentally hold a reference to something you shouldn't, or if the garbage collector's behavior changes in some later version (or alternative runtime).

[-]

daidoji70@reddit

Man that's a good writeup but that pattern just feels dirty.

[-]

TomWithTime@reddit

I read it expecting to see a homebrew implementation of a deferred promise. You can create a cancel method easily: create a wrapping class around a promise that accepts the promise and then captures the reject function and invokes it from a cancel function.

First saw that at att where some other scopes would explicitly call succeed / cancel to signal some code elsewhere that was waiting.

[-]

Blue_Moon_Lake@reddit

And at each "breakpoint" you await the deferred promise?

[-]

TomWithTime@reddit

Pretty much. I think it originally comes from jQuery (jquery deferred) and we made the promise thing in our efforts to move away from jQuery. If you look at some code examples or discussions around that object you'll see how they can be used. It's been 8 years so I haven't used it in a while but I think it was essentially a more flexible promise.

I didn't use it in any of my own projects after I left. Er, after att decided to close a dozen buildings and teams related to business operations and replace all in house development with ServiceNow and manage all of their bizops in Bangalore.

[-]

Blue_Moon_Lake@reddit

Good thing we now have Promise.withResolvers()

[-]

TomWithTime@reddit

That's cool, the equivalent code snippet in the documentation for that is what I had in mind

[-]

aardvark_lizard@reddit (OP)

It does feel dirty, but it's worked well for us for years! It makes the user-facing API more idiomatic

[-]

sliversniper@reddit

It's true in most languages.

By cancel, it's just inserting if token.isCancelled { return_or_throw } whenever you see fit.

Generator yield the same thing with more hidden magic.

And some language just hide/insert the token from you, and let you use it their way.

If it's up to the machine momentarily randomly pick a line to stop, the state might be inconsistent, good luck debugging that.

Any function should always run to the end, and respect the control transfer statements like return/yield/throw/goto/panic etc.

[-]

Blue_Moon_Lake@reddit

In NodeJS you can use AsyncLocalStorage to store your workflow AbortSignal and wherever you can and want to handle the aborted workflow, you can do so cleanly. Without needing to pass the signal around.

const storage = new AsyncLocalStorage();

function runInterruptibleWorkflow(callable: () => Promise<void>) {
    const abort_controller = new AbortController();
    const { promise, resolve, reject } = Promise.withResolvers();

    storage.run(
        { abortSignal: abort_controller.signal },
        (): void =>
        {
            Promise.try(callable).then(resolve, reject);
        }
    );

    return {
        abortController: abort_controller,
        promise: promise,
    };
}

[-]

lean_compiler@reddit

this pairs super well with middlewares to setup aborts on request cancellations.

but still, we do need to check with signal on every major checkpoint and return early right? unlike with asyncio tasks in python where we can cancel and it'll kill the thing on it's own?

[-]

Blue_Moon_Lake@reddit

If you use using, you can pretty much handle it with a single call to a function

function checkWorkflowSignal() {
    if (storage.getStore().abortSignal.aborted) {
        throw new Error("Workflow was aborted");
    }
}

You need to decide what happen on cancellation still, it can't just die silently anywhere. It would be dangerous.

[-]

YumiYumiYumi@reddit

Not resolving means that your code has to be written to tolerate being stopped in the middle. Which is something that can be difficult if you're handling resources or anything that needs to be cleaned up after the point where your code could stop.

I think exception throwing is a perfectly fine way to handle cancellation. Most try-catch blocks would likely be to handle errors more gracefully, but if you're using try-catch to implement fallbacks, you need to be more careful of what you're catching because you won't necessarily want to continue on any error.

[-]

mpyne@reddit

Note that After interrupt is not printed. Once the interrupt is hit, the program exits cleanly with no errors. That behavior might surprise you.

This pattern of extant promises not preventing program shutdown bit me a lot when I was first learning about promises trying to use the Perl Mojolicious library to drive a build script.

It did make sense once I understood how things worked but it was stuff like that which kept showing me I didn't yet understand how things worked.

[-]

RaccoonElaborate@reddit

promise deez nuts

they were removed in surgery of cancer