RAG re-index messages keep failing after poison payloads reach the city’s embedding worker. Where should those failed Service Bus messages go for investigation?
Select an answer to reveal the explanation.
Short Explanation
You can send failed RAG re-index messages to the dead-letter queue, where your ops team can inspect them without losing evidence or blocking the main queue. From there, you can correct the issue and replay messages under control.
Full Explanation
Poison or repeatedly failing RAG re-index messages should leave the active municipal work queue without disappearing. Service Bus dead-letter queues are designed for this: after the maximum delivery attempts, or when the embedding worker explicitly dead-letters a payload, it moves to the queue or subscription’s dead-letter sub-queue with a reason and description. Operators can inspect the original body and user properties, fix schema or blob issues, and replay under control, preserving evidence for city AI ops while unblocking healthy re-index traffic. Deleting failed messages immediately loses the payload that could explain why embeddings did not update, and can hide systemic bugs such as a bad chunker, expired storage SAS, or schema drift. Keeping poison messages locked on the queue indefinitely is not a viable investigation route: locks eventually expire, workers retry the same bad message, and useful work waits as the queue stays busy. Forwarding every failed payload to public Blob Storage without access controls risks exposing sensitive resident or ordinance content; it belongs in governed storage with RBAC. Exam caveat: dead-lettering is not automatic success—teams must monitor DLQ depth and define replay runbooks. Practical check: submit a known-bad re-index message, confirm it reaches the dead-letter queue with a clear reason code, alert when DLQ depth exceeds zero, and replay only after verifying the embedding worker can parse the corrected payload.