Files
Fuchs_Intranet/Fuchs/Docs/Concepts
StefanandClaude Sonnet 5 bcf1f2dbb6
Playwright Tests / test (push) Canceled after 0s
feat: migrate DB error logging onto the generic OCORE MultiLogger SQL sink
Retires Fuchs_intranet.debug_log() and every direct EXECUTE [dbo].[fds__admin_logdebug]
call in favor of a single path: ILogger. A new SQL log sink (OCORE.MultiLogger.SqlLoggerProvider,
gated by Fuchs:Logging:SqlSink:Enabled, default on) mirrors every _logger.LogWarning/-Error/
-Critical call into [dbo].[fds__debuglog] via a new fds__admin_logdebug_ext proc, at Warning+.

- Program.cs registers the sink and RequestLogScopeMiddleware (request id/path/authenticated
  user, pushed after UseAuthentication) so every log line in a request — including ones written
  deep inside OCORE's SQL helpers — is attributed automatically.
- FIS_SQLOptions, IntranetController.Do's catch-all, PdfPreviewAsync, and the banking-upload
  handlers now log once, with an explicit EventId preserving the exact CodeReference text the
  retired debug_log() calls used to write, so existing dashboards/queries over fds__debuglog
  keep working unchanged.
- Fuchs_DataService/FdsMfr.cs's FdsSqlOptions had the identical double-write hazard (it's hosted
  in the same process per ADR 0010) — the original 2026-09-16 log review's mfr__getSchema/
  fds__getUpdateableRequests deadlock rows came from exactly this class. Fixed the same way.
- fds__debuglog gains LogLevel/Machine/Category/Account/AuthUser/IsDebug columns; the legacy
  fds__admin_logdebug proc is left in place unused, not dropped.
- FdsDebug.DebugLog (Fuchs_DataService's other ~9 call sites) deliberately left on its direct
  DB-write path — no ILogger call sits alongside it there, so no duplication risk today.

See ADR 0024 (supersedes 0023) and Docs/Concepts/error-logging-pipeline.md.

New tests: ErrorLoggingTests (FIS_SQLOptions), FdsSqlOptionsTests, RequestLogScopeMiddlewareTests.
694/694 pass (the 4 PdfPipelineTests failures seen under full-suite parallel runs are a
pre-existing, unrelated PdfSharp global-font-resolver test-isolation flake — they pass both
individually and in most full-suite runs).

Bumps the OCORE submodule to 3137b56 (SQL sink hardening: redaction matches short fragments
as whole identifier segments, per-entry-tolerant serialization, lazy dataSerialized, opt-in
SqlLoggerOptions.IncludeCategory, LogEntry.Category/AuthUser capture).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-16 17:20:06 +02:00
..

Concepts

This folder holds living design write-ups of how a subsystem currently works: its moving parts, data flow, and how they fit together. Unlike ../Decisions, concept docs are not immutable — keep them in sync with the implementation as it evolves.

What belongs here

"How does the notification pipeline work end to end" is a concept doc. "Why did we choose SignalR over polling for it" is a decision. A single feature area typically has one concept doc and may reference several decisions that shaped it.

File naming

kebab-case-topic.md (no numbering — concepts aren't sequential events).

Required YAML frontmatter

---
status: Active            # Active | Deprecated
lastUpdated: 2026-07-03
applyTo:                  # glob(s) — files/areas this concept describes
  - "Fuchs/Notifications/**"
relatedDecisions:         # filenames in ../Decisions this concept implements
  - "0001-domain-events-and-notification-triggers.md"
---

Agents must scan the YAML frontmatter of every file in this folder first and only read the full body of concepts whose applyTo glob matches the files they're about to touch, or whose subject is otherwise clearly relevant.

Body template

# Topic

## Summary
One paragraph: what this subsystem does and why it exists.

## How it works
The mechanics — components, data flow, sequencing. Diagrams (ASCII/mermaid)
welcome where they clarify.

## Key files
Bullet list of the primary files/classes involved.

## Related decisions
Links to the ADRs in `../Decisions` that shaped this design.

Rules

  • Keep concepts current. When you materially change how a documented subsystem works, update its concept doc in the same change — don't let it drift from the code.
  • Create a concept doc for new non-trivial subsystems. If you build something a future agent would need a paragraph of context to safely modify, write that paragraph here instead of making them re-derive it from the diff.
  • Concepts describe current behavior. If something changes, edit the doc in place — don't append a changelog inside it (git history is the changelog).