bcquality/microsoft/knowledge/upgrade/do-not-block-upgrade-on-data-errors.md
Jesper Schulz-Wedde 2b5550c346
Some checks failed
Validate knowledge index / validate-index (push) Has been cancelled
Validate AL review fixtures / validate-review-fixtures (push) Has been cancelled
Validate frontmatter and structure / validate (push) Has been cancelled
Improve partner onboarding and documentation navigation (#174)
Lead with a complete plugin quick start and add task-oriented usage, troubleshooting, customization, and contribution guides. Preserve the broader plugin framing, correct conflicting contract guidance, support Agents folder reviews, and align repository validation. Convert existing sample references to clickable links without changing knowledge rules.

Co-authored-by: Jesper Schulz-Wedde <jesper.schulzwedde@microsoft.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
2026-09-09 17:31:03 +02:00

1.5 KiB

bc-version domain keywords technologies countries application-area
all
upgrade
error-handling
telemetry
session-logmessage
blocking
graceful
al
w1
all

Log telemetry; do not raise errors that block the upgrade

Description

When upgrade code encounters unexpected data — a record it expected to find, a relationship it assumed to be intact — the response is to log telemetry and continue, not to raise an error. A runtime error inside an upgrade codeunit aborts the upgrade for the company or database, leaving the customer stuck on the old version. Customers should not be blocked from upgrading because of a data inconsistency that an upgrade routine could not have anticipated.

Best Practice

When an upgrade procedure detects something missing, call Session.LogMessage with a stable event ID, classify the message verbosity (typically Warning), and exit the procedure so the rest of the upgrade can proceed. The platform telemetry then surfaces the situation to the partner without breaking the customer.

See sample: do-not-block-upgrade-on-data-errors.good.al.

Anti Pattern

Calling Record.Get(Key) (or any other erroring API) and letting the error propagate out of the upgrade trigger. The first tenant with imperfect data fails to upgrade, and the failure surfaces as a hard upgrade error rather than as a telemetry signal.

See sample: do-not-block-upgrade-on-data-errors.bad.al.