When a picked file fails a restriction, core.addFiles() emits restriction-failed and then rethrows:
} catch (error) {
this.emitter.emit("restriction-failed", { error });
throw error;
}The onChange that getInputProps() wires onto the hidden input calls it as fire-and-forget:
if (fileList) { void addFiles(Array.from(fileList)); }So every restriction failure through the file input produces the event (which the app handles) plus an unhandled promise rejection. In prod that means each user-facing "file too large" also logs an uncaught rejection to the console — and to Sentry — even in apps that fully handle restriction-failed. We had to add a window.onunhandledrejection filter to keep our error monitoring clean, which is not great.
Since the event is already emitted, catching inside the getter's onChange (or not rethrowing on the input path) would fix it without changing the API for callers who await addFiles() directly.
Small related thing: the restriction-failed payload is typed { error: unknown } — typing it as UpupError would remove a cast in every handler.
When a picked file fails a restriction,
core.addFiles()emitsrestriction-failedand then rethrows:The
onChangethatgetInputProps()wires onto the hidden input calls it as fire-and-forget:So every restriction failure through the file input produces the event (which the app handles) plus an unhandled promise rejection. In prod that means each user-facing "file too large" also logs an uncaught rejection to the console — and to Sentry — even in apps that fully handle
restriction-failed. We had to add awindow.onunhandledrejectionfilter to keep our error monitoring clean, which is not great.Since the event is already emitted, catching inside the getter's
onChange(or not rethrowing on the input path) would fix it without changing the API for callers whoawait addFiles()directly.Small related thing: the
restriction-failedpayload is typed{ error: unknown }— typing it asUpupErrorwould remove a cast in every handler.