bcquality/custom/knowledge/architecture/log-writes-must-survive-rollback.md

bc-version	domain	keywords	technologies	countries	application-area
all	architecture	logging rollback session transaction error-log web-service telemetry	al	w1	all

Log writes must survive transaction rollback

Description

The naive instinct when adding logging is to insert the log record inside the running transaction. That log has a fatal blind spot: when the operation ERRORS, the transaction rolls back — and takes the log entry with it. The result is a log that faithfully records every success and silently loses exactly the failures it exists to capture.

Observed in production design (Wareco IC, 2026-07-02): a log of errors and duration per web-service call needed entries to persist even when the business transaction was rolled back. The correct pattern — writing the log from an ISOLATED SESSION so its commit is independent of the caller's transaction — had previously cost a developer most of a day to discover.

Rule

A log whose purpose includes capturing FAILURES must write its entries in a transaction that is independent of the operation being logged:

1. Isolated session write: start a separate session (StartSession on a codeunit that inserts the log record and commits) so the entry persists regardless of what happens to the caller's transaction.
2. The log codeunit does ONE thing: insert + implicit commit. No business logic rides along in the isolated session — anything committed there escapes the caller's rollback by design.
3. Duration/telemetry fields are captured in the caller and passed as parameters — the isolated session must not re-read state that the rollback may erase.
4. Logs that only record successes (audit of committed work) may stay in the main transaction — this rule targets error/diagnostic logs specifically.

What NOT to do

• Do not Insert the error-log record in the same transaction as the operation — the error you most need to see is the one that deletes it
• Do not "fix" it with Commit before the risky call — a stray Commit breaks the caller's atomicity and violates posting-routine rules
• Do not swallow errors to keep the log alive (if Codeunit.Run then... without re-raising) — the log must observe the failure, not suppress it

Signal to watch for

A log table whose entries are inserted in the flow they measure, with no isolated-session writer — combined with any error path. In review: search callers of the log-insert for surrounding Insert/Post in the same transaction scope.

Message to developer

When an in-transaction error log is found, explain: entries vanish on rollback, so the log is blind to failures; route the write through an isolated session (StartSession → insert+commit codeunit) with values passed as parameters.