Service Bus dead-letters pile up for a grants-processing AI job. How should KQL help?
Select an answer to reveal the explanation.
Short Explanation
You can turn dead-letter reasons into a clear guide for fixing rejected messages. KQL groups those clues so you can address poison payloads instead of guessing.
Full Explanation
For a grants-processing AI job, use KQL to summarize dead-letter reason fields and guide poison-payload fixes. Reasons can show whether failures come from deserialization errors, validation rejects, exceeded delivery counts, or downstream dependency faults, helping engineers correct the payload contract or consumer logic rather than blindly replaying messages. Tracking active queue depth over time can reveal backlog size and throughput changes, but without examining dead-letter reasons it does not explain why messages were rejected. Purging the dead-letter queue nightly without analyzing reasons destroys forensic evidence and may discard grant submissions that need remediation and resubmission. Disabling dead-lettering so failed messages vanish silently hides data loss in a financially sensitive workflow. Exam caveat: dead-letter subqueues contain messages that cannot be processed successfully under current rules, so fix the root cause before reprocessing. Ensure diagnostics or application logs capture reason codes and descriptions without exposing full sensitive grant PII in unrestricted workspaces; delivery-count or lock-duration misconfiguration can also inflate dead-letters independently of payload bugs. Practical check: query and chart reasons over recent intervals, triage the most common classes, patch the consumer or producer contract, replay a sampled fixed batch, and confirm new dead-letter rates fall. Alert when dead-letter depth or reason spikes exceed thresholds during grant submission windows.