After 'Dev' deployed a service using Azure ServiceBus, a particular queue/client was receiving errors.

Dev: "Looking at the logs, client is getting faulted."
Me: 'What is the error being logged?'
Dev: 'Client is faulted'
Me: 'No, that is our error when the client is either unable to connect or there is an exception in the middle of sending a message. What is the exception from Azure?'
Dev: 'Client is faulted. That's it. I'm going to have to re-engineer the code to implement a retry policy.'
<OK, I smell someone cooking up some solution finding, so I dig into the logs a little further>
Me: "Looks like an invalid connection string. The actual exception being thrown and logged is from the Azure client connection string builder. The value cannot be null."
Dev: "No, I'm looking right at the connection string in the config. Looks fine."
Me: "Looks correct on your machine, but what is actually being deployed to the server?"
<I could tell he was getting agitated>
<Dev clicks around, about 10 min. later>
Dev: "Aha!..I found it. The connection string in the config on the main branch is wrong, in fact, the entry is missing."
<dev fixes, re-deploys, life is good, I document the error and the root cause>
Boss: "Great job Dev."

*sigh* ..go teamwork?

  • 10
    I always credit to those who found the solution. Always! It’s shameful to use other’s creative ways to solve the problem as your own unless credited to
  • 2
    Good job @PaperTrail.
    Root cause debugging is a skill set in its own apparently.
  • 0
    @PaperTrial sad story. I know that feel. You will be recognized someday at least that was my experience.
Add Comment