fix(ui): two user-facing notifications never appear, because autoClose defaults to 0 #437

Summary

Two Notification calls meant to surface a failure to the user never render as toasts. Both omit autoClose, and JupyterLab's default for that option is 0, which means "retained in the notification center but never displayed." The user gets no visible signal at the moment the thing fails; the message only exists behind the notification-center bell.

Details

NotificationManager.notify defaults the option to zero, and says so:

// node_modules/@jupyterlab/apputils/lib/notification.js
options: {
    // By default notification will be silent
    autoClose: 0,
    ...
}

Notification.IOptions.autoClose is documented as the toast duration, where a non-positive value keeps the entry out of the toast layer entirely.

The two affected call sites pass a message and nothing else:

• src/terminal-drag.ts:327 - Notification.error(Terminal drop upload failed for ${head}${tail}). A drag-and-drop upload into a terminal fails and the user sees nothing.
• src/chat-sidebar.tsx:2305 - Notification.warning(Could not attach: ${errors.join('; ')}). The in-tree comment above it explains the choice of a notification specifically to avoid "slipping a chat-message-notice into the transcript, which can scroll out of view" - so the intent was clearly a visible, non-transcript signal. It is currently less visible than the transcript notice it replaced.

For contrast, src/index.ts:838 passes { autoClose: 5000 } and does toast correctly, which is why the MCP-save failure is visible and these two are not.

Impact

Silent failure in both cases, in the direction that matters: the user believes their upload or attachment succeeded. The notification-center bell does increment, so the information is technically recoverable, but nothing draws attention to it at the time.

Proposed direction

Pass an explicit autoClose at both sites. JupyterLab's own ToastContainer default is 5000, which src/index.ts:838 already matches, so { autoClose: 5000 } keeps the three sites consistent.

Worth a wider check as part of the fix: any future Notification.* call that omits the option has the same failure mode, and nothing in the repo flags it. A short comment at the first call site, or a thin wrapper that requires the duration, would stop the next one silently going the same way.

Provenance

Found while reviewing #430 (which adds a third notification call site and does pass autoClose). Unrelated to that change; filing separately so the fix is not buried in it.