- Updated FdsSqlOptions to accept an optional ILogger parameter for improved error logging. - Modified FdsMfr and FdsMfrClient classes to pass the logger instance to FdsSqlOptions. - Added detailed error logging in various methods to capture SQL execution issues and file handling errors. - Improved documentation for FdsSqlOptions to clarify logging behavior. - Updated Archive class to log compression errors, enhancing traceability of failures. - Adjusted project configuration to suppress specific warnings related to transitive dependencies. - Added NuGet.config to define package sources for dependency management. - Updated submodule references for OCORE and related projects.
2.9 KiB
2.9 KiB
status, date, applyTo, supersededBy
| status | date | applyTo | supersededBy | ||||
|---|---|---|---|---|---|---|---|
| Accepted | 2026-07-03 |
|
0002 — Backend notifications reach the GUI via a SignalR push to every logged-in session
Context
Domain events (see 0001) need to reach whichever browser session(s) a user has open, in near real time, without the client polling.
Decision
NotificationHub(Fuchs/Notifications/NotificationHub.cs) is an[Authorize]SignalRHubmapped at/notificationsinProgram.cs(app.MapHub<NotificationHub>("/notifications")).EventService.PublishAsyncsends everyGuiNotificationto_hub.Clients.All.SendAsync("notification", notification, ...). Delivery is currently broadcast to all connected (authenticated) clients, not targeted per-user — any logged-in session receives every notification.- Publish failures are caught and logged (
_logger.LogWarning) rather than thrown — a notification-delivery failure must never fail the underlying business operation that triggered it. - On the client,
$fis.notifications(Fuchs/js/intranet/fis_main.js) opens the SignalR connection once a logged-inuseraccount_idis known, listens for the"notification"event, and callspush(notification)to render a dismissible toast into#notification_frame. The toast is styled bynotification.severity("error"vs"info"), giving failures a distinct highlighted appearance from successes. GuiNotification.Severityis derived byEventService.IsFailurefrom theDomainEventType— failure event types render as"error", everything else as"info".
Consequences
- Any new
DomainEventTypethat represents a failure must be added toEventService.IsFailureor it will render as a plain info toast instead of being visually flagged. - Because delivery is broadcast (not user-scoped), notifications are not a
substitute for private/sensitive data —
Context/Messagecontent must stay appropriate for any logged-in user to see. If per-user targeting becomes necessary, that is a new decision (SignalR groups keyed by user ID), not a silent change to this one. - The hub requires authentication; unauthenticated sessions never connect and never receive notifications.
- Frontend rendering logic lives in
fis_main.js/fis.js— keep the builtwwwroot/web/fis.js/fis.min.jsin sync via the gulp build (seeCLAUDE.mdBuild & Test) whenever the notification client code changes.
Alternatives considered
- Per-user SignalR groups: more correct long-term but adds group join/leave lifecycle management; deferred until a concrete need for private notifications arises.
- Server-Sent Events / long polling: rejected — SignalR was already the chosen real-time transport and needs no extra infrastructure.