Shouldn't the execution of callbacks be non-blocking?

[ukaj808]

Hey!

Me and my team implemented a micro-frontend architecture and decided to use our own implementation of an event bus for communication between MFEs.

We ran into an issue where a MFE passed an async callback on subscription to an event
(with a Promise return type, so the ts compiler didn't complain) and the async call they made failed without a catch. This ended up blocking 1. the rest of the callbacks after it 2. the dispatchEvent method. I mean blocking here in the sense that the uncaught error killed the execution. But that method could also technically block the thread if it made a time consuming api call, for example.

It seems you have the same implementation; and since this is the most popular event bus library in the MFE community, i'm starting to doubt my thinking here lol... What do you think?

Here is the code im referencing in your implementation:

event-bus/src/event-bus.ts

Lines 150 to 155 in d89b8bb

	for (const id in channelObject) {
	// istanbul ignore if - ignore robustness check
	if (id === '__replay' || id === '__schema') continue;
	if (typeof channelObject[id] !== 'function') continue;
	channelObject[id]({ channel, payload });
	}

EDIT: Turns out that the callback wasn't async; but it threw a runtime exception.... Simply wrapping the execution of the callback in a try catch makes it more "non-blocking". But technically if someone's callback pauses the main thread e.g.

function wait(ms){
   var start = new Date().getTime();
   var end = start;
   while(end < start + ms) {
     end = new Date().getTime();
  }
}

then it would block the rest of the callbacks from running. To resolve this, we could wrap the execution of the callbacks in a setTimeout function to offload the execution of the callbacks to the event loop