Possible race condition in fetch setup

[RubenVerborgh]

The code at

solid-client-notifications-js/src/notification.ts

Lines 93 to 118 in bcb53a4

	constructor(
	topic: string,
	protocolList: protocols[],
	options: BaseNotificationOptions = {}
	) {
	const { gateway, host, features = {}, fetch: fetchFn } = options;
	this.topic = topic;
	this.protocols = protocolList;
	this.features = features;
	this.gateway = gateway;
	this.fetch = fetchFn || crossFetch;
	// Attempt to load the fetch function from the default session if no fetchFn was passed in.
	if (!fetchFn) {
	// We don't care if this errors.
	/* eslint @typescript-eslint/no-floating-promises: 0 */
	BaseNotification.getDefaultSessionFetch().then(this.setSessionFetch);
	}
	this.host = host || BaseNotification.getRootDomain(topic);
	}
	setSessionFetch = (sessionFetch: typeof crossFetch = crossFetch): void => {
	this.fetch = sessionFetch;
	};

seems to suffer from 2 issues at first sight:

• The fetch member is temporarily set to crossFetch and there is no indication of the switch happening. So when accessing the object quickly after creation, an unauthenticated fetch might accidentally be used.
• There is no error handling. Even though the code says we "don't care" whether something errors (presumably because of the fallback to crossFetch), the promise rejection will still go unhandled and cause application errors/warnings. And I'd be surprised if we really don't care.

Both issues can be mitigated by temporarily assigning a function to this.fetch that stores all of its calls until the fetch object resolves. Something like:

const fetches = [];
this.fetch = (...args) => {
  return new Promise((reject, resolve) => {
    fetches.push({ args, reject, resolve });
  };
}

and then upon setting this.fetch, calling all fetches and resolve or reject depending on whether an error occurred or not.

This holding pattern can also be abstracted into a utility function.