profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/benjamingr/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

benjamingr/bluebird-api 36

Bluebird compatible API on top of native promises.

benjamingr/cancellation-use-cases 7

Like https://github.com/nodejs/promise-use-cases but for cancellation ^^

benjamingr/Auto-Translate 6

Translating multiple languages in JS/HTML through JSON seamlessly

addaleax/node 4

Node.js JavaScript runtime :sparkles::turtle::rocket::sparkles:

benjamingr/benjamins-demo-repo 1

Some Demo Repo thing

benjamingr/blaze-lib 1

Automatically exported from code.google.com/p/blaze-lib

benjamingr/buffer 1

The buffer module from node.js, for the browser.

benjamingr/bullmq 1

BullMQ - Premium Message Queue for NodeJS based on Redis

benjamingr/cancellation-propagation-example 1

Please don't use this ^^ I have no idea if this idea is good.

issue commentnodejs/node

Exclude `AbortError` from unhandled rejections?

@Jamesernator

This asynchronous stack stuff would be rather nice in JS, however it essentially Zones which have been rejected as TC39 before.

Note that both:

  • Node.js (V8 really) already has asynchronous stack traces for async functions :)
  • As for actual context or stacks - we have AsyncLocalStorage which is similar to zones (sans error handling) in its ability to carry around state in asynchronous context on-top of async_hooks. Whether or not that's a good idea? ¯_(ツ)_/¯
benjamingr

comment created time in 2 days

issue commentnodejs/node

Exclude `AbortError` from unhandled rejections?

@ronag note that @ljharb's interpretation of what the language says is nuanced. The language does not specify what the host should do on unhandled rejections or uncaught exceptions - that is left to host-hooks to decide (e.g. HostPromiseRejectionTracker - 25.6.1.9 in the spec).

Different platforms (e.g. Node.js and the browser) do different things here because of different requirements (ux in browsers means errors just get logged, safety in Node.js means the process aborts).

The fact the language does not treat unhandled rejections in a certain way isn't evidence towards how Node.js should behave - it just means the language doesn't see it as its business to define these semantics - probably since it couldn't do so well given conflicting requirements from implementors.

benjamingr

comment created time in 2 days

PullRequestReviewEvent

delete branch kriskowal/q

delete branch : benjamingr-patch-1

delete time in 3 days

push eventkriskowal/q

Benjamin Gruenbaum

commit sha d639e8d74e332d4f940521fca5541710d3162f73

Add note

view details

Benjamin Gruenbaum

commit sha 736018ba866c435e9a2cf442817e5a9abe266d94

Update README.md Co-authored-by: Kris Kowal <kris@cixar.com>

view details

Benjamin Gruenbaum

commit sha f414202ba1f000de64f6a14fcd462352d77e21e6

Update README.md Co-authored-by: Kris Kowal <kris@cixar.com>

view details

Benjamin Gruenbaum

commit sha 3ef3318582e6ca7f50e3c96f9b41a0bfff453198

Update README.md Co-authored-by: Kris Kowal <kris@cixar.com>

view details

Benjamin Gruenbaum

commit sha 0dc3d80508dfb4fcc36241474a204c6eafa08cf6

Update README.md Co-authored-by: Kris Kowal <kris@cixar.com>

view details

Benjamin Gruenbaum

commit sha d180f4a0b22499607ac750b56766c8829d6bff43

Merge pull request #854 from kriskowal/benjamingr-patch-1 Add note

view details

push time in 3 days

PR merged kriskowal/q

Add note

I am happy to do phrasing/content changes :)

@kriskowal

Fixes: https://github.com/kriskowal/q/issues/853

+11 -0

0 comment

1 changed file

benjamingr

pr closed time in 3 days

issue closedkriskowal/q

Add warning and recommend native promises

Hey @kriskowal ,

Is it OK if I add a warning to the readme recommending native promises?

A discussion with @domenic yesterday reminded me a lot of people still use promise libraries. I've made the Bluebird warning much sterner.

I don't have the same sense of collaboratorship here as I do in Bluebird since I was made a collaborator pretty much after the development of the library has stopped - so I don't feel like I have the mandate to add the warning without asking first.

closed time in 3 days

benjamingr

push eventkriskowal/q

Benjamin Gruenbaum

commit sha 0dc3d80508dfb4fcc36241474a204c6eafa08cf6

Update README.md Co-authored-by: Kris Kowal <kris@cixar.com>

view details

push time in 3 days

push eventkriskowal/q

Benjamin Gruenbaum

commit sha 3ef3318582e6ca7f50e3c96f9b41a0bfff453198

Update README.md Co-authored-by: Kris Kowal <kris@cixar.com>

view details

push time in 3 days

push eventkriskowal/q

Benjamin Gruenbaum

commit sha f414202ba1f000de64f6a14fcd462352d77e21e6

Update README.md Co-authored-by: Kris Kowal <kris@cixar.com>

view details

push time in 3 days

push eventkriskowal/q

Benjamin Gruenbaum

commit sha 736018ba866c435e9a2cf442817e5a9abe266d94

Update README.md Co-authored-by: Kris Kowal <kris@cixar.com>

view details

push time in 3 days

issue commentnodejs/node

Exclude `AbortError` from unhandled rejections?

@mcollina good question, I think a lot of people use unhandledRejection for monitoring and it restarts the server. Referencing my experience from ±5 years ago basically:

  • You have a server.
  • You restart the server on unhandledRejection.
  • Azure/AWS/GCP/DO/whatever restarts your server for an OS update. You get a SIGINT and gracefully shutdown.
  • A lot of operations get cancelled because you propagate AbortSignals everywhere - some without explicit handling of errors because typically the operations they cancel failing is a programmer failure and should restart the server on its own.
  • You wake up in the middle of the night because your code logged a thousand unhandledRejections very quickly and your monitoring saw your app's many fatal errors and assumed the server is failing to restart.

It's quite a specific case but one that happened to me in the past. If AbortErrors don't go through the same path you wouldn't have this problem. Is it worth it? Maybe?

I think a case where ignoring them is unsafe would settle this (in my book) towards not treating them differently. Better to wake up someone in the middle of the night and not fail catastrophically and the workaround of filtering yourself in a process.on('unhandledRejection' handler is acceptable.

benjamingr

comment created time in 3 days

issue commentnodejs/node

Exclude `AbortError` from unhandled rejections?

I don't have a clear opinion on this topic yet, but I feel like if we add a mechanism that allows to opt out of unhandled rejections for some classes, it should be public API and not only available through AbortError

It could be a symbol for example or a brand/utility. bikeShed.markAsNotUnhandled(error) that takes an error and tells it to skip unhandledRejection/uncaughtException.

Though I think we're mostly missing someone with a strong opinion to say "this is a good/bad idea" now. I'll ping some friends who work on other platforms and ask.

benjamingr

comment created time in 3 days

issue commentnodejs/node

Exclude `AbortError` from unhandled rejections?

There was an attempt made in this direction, but it didn't go well in tc39

Yes, that was the reference. I was very much in favour of that effort back then :)

I haven't used unhandledRejection much, so I don't have a strong feeling here.

Unlike browsers - Node.js servers crash on uncaught exceptions (and unhandled rejections) to prevent cascading failures - in the browser this being uncaught isn't a big deal because in browsers AbortErrors will just cause console.logs when unhandled.

Intuitively - AbortError shouldn't do that and doesn't have the same problem that ignoring/suppressing errors does on the server but I am mostly waiting for someone to have a strong opinion on the topic.

benjamingr

comment created time in 3 days

PR opened kriskowal/q

Add note

I am happy to do phrasing/content changes :)

@kriskowal

Fixes: https://github.com/kriskowal/q/issues/853

+11 -0

0 comment

1 changed file

pr created time in 3 days

create barnchkriskowal/q

branch : benjamingr-patch-1

created branch time in 3 days

issue commentnodejs/node

Exclude `AbortError` from unhandled rejections?

(I have not made up my mind yet regarding this being a good/bad idea)

benjamingr

comment created time in 3 days

issue openednodejs/node

Exclude `AbortError` from unhandled rejections?

Hey, following a few discussions here https://github.com/tc39/proposal-cancellation/issues/22 I'm wondering if AbortError should be excluded from generating an unhandledRejection. Aborting things isn't really an error (it's best effort) and the fact it's even an error and not a third-state running finally clauses only is unforunate.

In addition there are several places we (and DOM APIs) already silently remove handlers without rejecting anything with an AbortError when an AbortSignal is aborted.

@ronag @jasnell @mcollina @jakearchibald @ljharb

created time in 3 days

issue commenttc39/proposal-cancellation

Cancellation protocol

See also the .timeout method discussion here https://github.com/whatwg/dom/issues/951 that could be another place to contribute.

rbuckton

comment created time in 3 days

issue commenttc39/proposal-cancellation

Cancellation protocol

@bergus hey :)

seems to conflict with

that's a pro/con list, I sure hope I was able to represent different perspectives I've been able to gather from stakeholders. Both these while conflicting are valid stances and both feel driven by empathy towards developers.

I can definitely see cancel signals that time out (with a set deadline, not an explicit .cancel() call) or those that are a combination of multiple other signals.

Neither of these things can be made possible with the existing AbortSignal and both are blocked on work. Combining AbortSignals is sticky. I started working on it here but got stuck - but this still very much needs to happen and new AbortSignal(...signals) makes a ton of sense for me to prevent leaks.

Timeouts (both adding AbortSignal support to a promises-version of setTimeout and adding support to a timeout parameter in AbortSignal) are blocked on effort (someone writing the spec, creating the wpts and talking to browsers).

You are very welcome to work on any of this and I'll be happy to help you with that. Note that I'm not sure why I'd want a timeout given it'd just be an alias for setTimeout(() => ac.abort(), ms) but composition is a big issue.

rbuckton

comment created time in 3 days

issue commenttc39/proposal-cancellation

Cancellation protocol

@Jamesernator regarding:

Throwing a DOMException feels pretty nonsensical in such a place, but I imagine people would want to detect it reliably, so we'd probably want to standardize AbortError as that specific name so that people can just do if (err.name === "AbortError")

After a conversion between Node core and several library authors as well as @jakearchibald we (Node) have decided to go with AbortError that's not a DOMException for APIs we are allowed to do that (Node will keep throwing DOMExceptions where it is required to by the spec).

So Node's AbortError (while keeping the DOMException's .code and .name) is not a DOMException - and so far no complaints in a year.

rbuckton

comment created time in 4 days

issue commenttc39/proposal-cancellation

Cancellation protocol

@MattiasBuelens in the hook-version of language-level cancellation:

  • Promises get a third parameter to then that takes a signal property.
  • The language defines and calls HostPerformAddEventListener('abort', Callback.
  • The callback (if the passed signal is aborted) calls HostPlatformAbortPromise(promise) which on the DOM side rejects the promise with an AbortError.

Something like this:

const clicked = once(document.body, 'click'); // new Promise(r => document.body.addEventListener('click', r, { once: true }))

class MyElement extends HTMLElement {
  constructor() {
    super();
    this.ac = new AbortController();
  }
  disconnectedCallback() {
    this.ac.abort();
  }
  connectedCallback() {
    once.then(paintDifferentlyBecauseClicked, null, { signal: this.ac.signal }) 
  }
}

Here the .then callback gets cleaned when the component unmounts using the signal.

(In terms of "should it pend forever", the ideal solution would have been third state semantics (call neither onFulfilled or onRejected but still run finally blocks).

rbuckton

comment created time in 4 days

issue openedkriskowal/q

Add warning and recommend native promises

Hey @kriskowal ,

Is it OK if I add a warning to the readme recommending native promises?

A discussion with @domenic yesterday reminded me a lot of people still use promise libraries. I've made the Bluebird warning much sterner.

I don't have the same sense of collaboratorship here as I do in Bluebird since I was made a collaborator pretty much after the development of the library has stopped - so I don't feel like I have the mandate to add the warning without asking first.

created time in 5 days

push eventpetkaantonov/bluebird

Benjamin Gruenbaum

commit sha e8006fc50dcfd6323639e2864aac9b52a9ec5466

Make native promises recommendation more direct

view details

push time in 5 days

issue commenttc39/proposal-cancellation

Cancellation protocol

So, after a few discussions more with involved parties:

Objections are:

  • There is no need for a protocol because people would not want several primitives for cancellation rather than one clear cancellation primitive to use.
  • Having several things that have the symbol capability is likely to confuse developers compared to passing tokens/signals around. We don't see people promise-subclassing or using thenables and it's creating confusion.
  • If CancelToken is spec'd, eventually it will be the "base type" for cancellation and iterating on it would be much hard than a primitive like AbortSignal in WHATWG. Users would have to rely on the "bare protocol" and adding utility methods and usability enhancements would be hard.
  • There are only very few examples of cancellable things in the ECMAScript language API.
  • There is a viable alternative - adding host hooks. That would mean anywhere the language may take CancelTokens it can accept AbortSignals instead.
  • Host hooks would also allow adding language syntax support.
  • All of the AbortSignal ergonomic issues are blocked on time/thought - composability for example. It is better to improve and iterate on the existing API.
  • Whether the protocol outlined above is actually good for cancellation (with .subscribe) is untested.

Pros are:

  • Cancellation is as fundamental to the language as promises.
  • Putting cancellation in the language would help provide syntactic support and refer to it in the spec.
  • AbortSignal is an EventTarget which would mean any environment implementing it would need to implement EventTargets.
  • AbortSignals make it easy to leak resources right now because you have to remember to unsubscribe twice (if the abort happens and if the operation completes successfully) to not leak a listener. A proposal can address that.
  • A protocol would encourage experimentation and innovation in this space (like it did for promises). It would be possible to make things that currently take a signal cancellable directly.

I'll elaborate on host-hooks in an issue.

rbuckton

comment created time in 5 days

issue commentnodejs/node

[Tracking Issue] New net/tls/udp API

Note that I have not said anything here yet about the actual API design other than this. I'd suggest that providing feedback on the API design in advance of actually seeing that design is quite premature.

I am attempting to provide feedback/opinions on the API design in advance because it seemed effective to bring such considerations before the majority of the work has been put in.

I hope it's clear that I am not criticising a design that doesn't exist yet without seeing it first :) I apologize for communicating poorly.

jasnell

comment created time in 5 days

issue commentnodejs/node

[Tracking Issue] New net/tls/udp API

Interesting. @martinthomson from your PoV based on https://github.com/mozilla/standards-positions/issues/431#issuecomment-690860040 how likely are Mozilla to revise this position if at all?

@jasnell one thing raised by Lucas is that there is nothing stopping us from creating a (tiny) standards body or just a standard like Promises/A+ and just implementing it.


In any case I would still caution to first try to implement this API on top of language level APIs like AsyncIterator and not web APIs.

jasnell

comment created time in 5 days

issue commentnodejs/node

[Tracking Issue] New net/tls/udp API

@uasan super interesting - but that looks blocked?

jasnell

comment created time in 5 days

issue commentnodejs/node

[Tracking Issue] New net/tls/udp API

@jasnell I personally would recommend taking the same approach as Promises/A+ for starters. If Node adopts the API and it's specified somewhere that should in practice be "good enough".

jasnell

comment created time in 5 days