### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Amodel) for similar behavior reports - [x] This report does NOT contain sensitive information (API keys, passwords, etc.) ### Type of Behavior Issue Other unexpected behavior ### What You Asked Claude to Do Summary When asked to write error-recovery / atomicity logic in AL (Business Central's language), Claude has a recurring tendency to reac

Claude generates AL/Business Central code that misuses [TryFunction] assuming it rolls back transactions

Status Open

Maintainer reply None cached

Activity 0 comments · opened Aug 13, 2026

Preflight Checklist

[x] I have searched existing issues for similar behavior reports
[x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

Summary

When asked to write error-recovery / atomicity logic in AL (Business Central's language), Claude has a recurring tendency to reach for the [TryFunction] attribute assuming that if an error occurs inside it, any database writes made during its execution get rolled back. This is factually wrong and can be dangerous: it leads to generated "safe" error-handling code that actually leaves partial/inconsistent writes committed to the database in a production ERP system.

What Claude Actually Did

Why this is dangerous

[TryFunction] in AL catches an internal Error() and returns false to the caller, but explicitly does not undo database writes made inside it — this is documented behavior, not an edge case.
Business Central on-premises even blocks writing to the database inside a [TryFunction] by default, precisely because of this.
The correct tool for "roll back these writes if any step fails" is Codeunit.Run() with its returned Boolean checked — a different mechanism with different guarantees.
A developer relying on Claude's generated code (or Claude itself, mid-task) can end up with partial/orphaned records in a live business database (invoices, ledger entries, settlement records, etc.) believing the operation is atomic when it isn't.
Reference (official docs, confirms the correct behavior)

https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-handling-errors-using-try-methods
https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/methods-auto/codeunit/codeunit-run-method
Repro context

Ask Claude to design error-recovery / partial-failure protection for a multi-step AL codeunit that inserts a header record plus several child records (e.g. "if creating the lines fails partway through, don't leave an orphaned header"). Observed twice in the same session: Claude proposed/used [TryFunction] specifically because it believed it would undo the header insert on failure — it does not.

Expected Behavior

Suggested fix / ask

Improve grounding on Business Central/AL-specific error-handling and transaction semantics so this distinction ([TryFunction] catches-but-doesn't-rollback vs. checked Codeunit.Run() which does) is applied correctly by default, without needing a human to catch it via testing/code review.

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

_No response_

Claude Model

Sonnet

Relevant Conversation

Impact

Critical - Data loss or corrupted project

Claude Code Version

Soy Claude Sonnet 5 (claude-sonnet-5), corriendo aquí como Claude Code.

Platform

Other

Additional Context