Skip to main content

Notification UI and Operations Limitations

Summary​

Every limitation below is a verified property of the reviewed source, grouped by concern and cross-referenced to the page carrying the evidence.

Audience​

Engineers, QA, support, DevOps engineers, architects, product owners and administrators.

Reference Content​

The verified reference material for this topic is set out in the sections below.

UI​

  • No preferences screen anywhere — the capability is invisible from every surface a user can reach.
  • No pagination, no infinite scroll and no way to reach older notifications; the inbox shows one server page.
  • No search, no date-range filter and no sorting control on any notification surface.
  • Filters are client-side over loaded items only, so filtering cannot reach beyond the returned page.
  • Category is inferred by ordered substring matching over free text, not from structured data, so a message mentioning two domains is categorised by the first term in a fixed order.
  • The interview category is reachable by inference but has no filter chip.
  • No detail view — an item without an action URL is marked read and nothing else happens.
  • No mark-as-unread, delete or archive action.
  • No real-time delivery; the header polls every 60 seconds and the inbox does not poll at all.
  • The template screen's placeholder hint is a hard-coded string in the component and can drift from what templates support.
  • No unsaved-changes guard on the template editor — switching event keys discards the draft silently.

Administration​

  • The Notification Center offers exactly one write action, retry, applied one message at a time.
  • The retry toast says the operation was queued; it is synchronous. The list is not refreshed afterwards.
  • The console's template panel shows legacy rows under column headers naming extracted-service fields, so channel and version render empty.
  • Extracted-service templates are read-only in the UI; creating or updating them requires the API.
  • No bulk retry, no filtering, no search and no paging beyond the first 100 rows on the failed and audit panels.
  • No UI to send a test notification, despite test hooks existing on the API.
  • No per-channel delivery health view and no provider configuration screen.
  • The template screen is registered twice in navigation, pointing at one route.
  • Navigation permissions and roles gate menu rendering only; no verified server-side counterpart exists.

Monitoring​

  • No metrics pillar at all — no meter, counter, histogram, gauge or metrics exporter.
  • Per-attempt duration is measured and persisted but never exposed as a metric.
  • No alerting, thresholds, service-level objectives or dashboard definitions in the repository.
  • Traces are recorded but exported nowhere unless an OTLP endpoint or console flag is configured; neither is set by default.
  • The two conditions most worth alerting on — broker disconnection and a growing failed queue — are observable only by polling, and the first only in logs.
  • The dashboard's pending tile has no matching field in the statistics contract and renders permanently unavailable.

Operations​

  • Health registers no checks, so a healthy response says nothing about the database, broker, consumer or providers.
  • The only positive signal that consumption is active is a single information log line.
  • A broker outage leaves a healthy-looking service consuming nothing, indefinitely.
  • An outage longer than the staleness window causes the oldest queued events to be silently skipped as stale.
  • Shutdown cancels in-flight processing rather than draining it.
  • Migrations run at startup on every instance, so rollouts produce concurrent migration attempts.
  • The migration skip flag also suppresses seeding — skipping migrations against an empty database yields no templates and universal no-template outcomes.
  • No bulk re-drive, no poison-message parking, no purge or archival procedure exists.

Configuration​

  • Channel provider selection is evaluated once at startup; changes require a restart.
  • The per-event channel override map is likewise startup-bound with no UI and no runtime reload.
  • No configuration validation — an unrecognised email provider silently falls back to console rather than failing fast.
  • No feature-flag system, no per-tenant configuration and no options-change listener.
  • The Observability Seq setting is present in configuration and read by nothing.
  • Committed development settings contain local placeholder credentials for the database and broker.

Troubleshooting​

  • Notification content and recipient addresses reach the logs when the console email provider or the placeholder senders are active.
  • Broker-driven processing carries no correlation scope in its log lines, so the richest processing path has the least log context.
  • Events published without a correlation identifier persist a null correlation and cannot be found through the audit correlation filter.
  • Failures cannot be filtered by tenant, channel or time window on any surface.
  • No supported resolution exists for a poison message, because requeue is unbounded and no dead-letter destination is wired.

Diagnostics​

  • Both test hooks are mapped unconditionally with no environment guard and no authorization, and can inject events and publish onto the shared platform exchange.
  • Swagger and its UI are enabled unconditionally, not gated on environment.
  • Attempt-level data is reachable per message only; there is no aggregate view.
  • Statistics are platform-wide and untenanted, with no time dimension.

User experience​

  • Write failures are swallowed and rendered optimistically; a failed mark-read silently reverts on the next load.
  • The header badge and the inbox badge derive from different sources and can disagree.
  • Truncation is invisible — no total, count or more-items indicator.
  • The richer inbox renders for non-employee-only users while describing itself as employee self-service.
  • Drawer has no dialog role or focus trapping; toasts have no live-region announcement.
  • Employees have no control over what they receive on any channel.

Classification​

Verified limitations. The UI and operations surface is Transitional; preferences UI, metrics, alerting and retention procedures are Not implemented; health, monitoring and administration are Partial.

Requires confirmation​

Whether user-facing screens migrate to the extracted service, production observability destinations, and ownership of the preference-management gap all require confirmation.

See Also​

Keywords​

  • Notification database
  • UI Limitations
  • Draft database documentation

Source References​

  • UI/salary-ui/apps/client-hrms-portal/src/pages/NotificationsPage.tsx
  • UI/salary-ui/apps/client-hrms-portal/src/pages/admin/NotificationTemplateManagementPage.tsx
  • UI/salary-ui/apps/client-hrms-portal/src/pages/admin/OperationsAdminPages.tsx
  • microservices/src/notification-service/Program.cs
  • UI/salary-ui/apps/client-hrms-portal/src/components/AppLayout.tsx
  • UI/salary-ui/apps/client-hrms-portal/src/dashboard/dashboardApi.ts
  • microservices/src/notification-service/Application/NotificationOptions.cs
  • microservices/src/notification-service/Messaging/NotificationEventConsumer.cs
  • microservices/src/notification-service/Api/NotificationEndpoints.cs
  • microservices/src/shared-kernel/Extensions/ObservabilityExtensions.cs

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-21
  • Review cycle: Quarterly