al-debug-logging

Adds temporary DEBUG-* FeatureTelemetry probes to AL code to inspect runtime behavior via telemetry.jsonl.

4|Updated Feb 22, 2026
One-click install
npx skills add https://github.com/FBakkensen/bc-agentic-dev-tools-marketplace --skill al-debug-logging-fbakkensen
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: al-debug-logging
Source: https://github.com/FBakkensen/bc-agentic-dev-tools-marketplace/tree/main/plugins/al-agentic-dev/skills/al-debug-logging
Command: npx skills add https://github.com/FBakkensen/bc-agentic-dev-tools-marketplace --skill al-debug-logging-fbakkensen

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? When AL runtime behavior diverges from what the source code suggests, tests alone cannot reveal which branch, subscriber, or code path actually executed. This Skill provides a disciplined loop for dropping temporary FeatureTelemetry.LogUsage probes, exercising the code, reading the captured telemetry, and removing the probes afterward. ## Core Features & Use Cases - Hypothesis-driven probing: Place one or two DEBUG-* prefixed FeatureTelemetry.LogUsage calls inside the exact branch under investigation, then correlate runs with DEBUG-ENTRY scope markers. - Telemetry capture workflow: Read probe output from .output/TestResults//telemetry.jsonl produced by the /al-build test harness, with guidance for other harnesses and the same-publisher constraint that silences probes. - Event subscriber probes for inaccessible code: Attach DEBUG-BC- subscriber codeunits to BaseApp, System Application, or third-party events when the source cannot be edited. - Use Case: A document posts successfully but pricing is wrong. Add a DEBUG-PRICING-FALLBACK probe inside the suspected branch, run the posting test, and discover from telemetry.jsonl that the no-lines branch ran instead — the mismatch is the bug. ## Quick Start Ask the AI to add temporary DEBUG-* telemetry probes to the AL code path you suspect, run the test harness, and report which branch actually executed from telemetry.jsonl.

Frequently Asked Questions about al-debug-logging

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug AL code paths at runtime in Business Central?

Add temporary FeatureTelemetry.LogUsage probes with a DEBUG- prefix inside the suspected branch, exercise the code via a test or page action, then search telemetry.jsonl for your DEBUG- events. Remove all probes once the question is answered.

How do I debug BaseApp or third-party AL code I cannot edit?

Create a temporary event subscriber codeunit in a non-shipping extension that subscribes to events the inaccessible code publishes, and emit DEBUG-BC-* FeatureTelemetry.LogUsage calls from it. Delete the subscriber codeunit when the investigation ends.

Why are my FeatureTelemetry.LogUsage probes not appearing in telemetry.jsonl?

Silent probes usually mean the same-publisher constraint is violated: the emitting extension and the Telemetry Logger subscriber must share a publisher in app.json. Also confirm the harness actually ran and that a Telemetry Logger codeunit is registered.

What is the difference between FeatureTelemetry.LogUsage and Session.LogMessage?

This workflow uses FeatureTelemetry.LogUsage exclusively, never Session.LogMessage. FeatureTelemetry events are captured by a Telemetry Logger subscriber and surface in telemetry.jsonl with fields like eventId, message, customDimensions, and callStack.

What data is safe to log in temporary debug telemetry probes?

Log only shape, not contents: counts, IDs, enum values, and booleans. Never log full record bodies, PII, credentials, tokens, or secrets, and use stable descriptive event IDs like DEBUG-PRICING-FALLBACK rather than numeric ones.