I made a post api call and got a "400 Bad Request" in the response. The response body has a one line message about an unspecified database commit transaction failure. After checking several times, I found that my request is 100% correct. Other people found the same issue too, despite making correct requests.

How should we deal with bugs like these ? Should we close such bugs because the issue does not occur anymore or demand an investigation ? I'd prefer the latter option though.

  • 1
    Can you pull logs from your server, take a look into them, you may find out why it happened. P.S. demand an investigation is a poor practice, as a tester (or a dev), we should not "demand" anything.
    – Yu Zhang
    Dec 8, 2017 at 23:55
  • 1
    @YuZhang - Unfortunately, QA is not allowed access to server logs. Hopefully, this will change later.
    – MasterJoe
    Dec 13, 2017 at 0:20

3 Answers 3


I like how Micheal Bolton (& James Bach) explains it in their Agile Testing Quadrants:

Investigate Mysteries & Tell compelling bug stories

So no, it is not correct and probably it is worth investigating further. If it happend once it will probably happen again.

So, what we typically call an intermittent problem is: a mysterious and undesirable behavior of a system, observed at least once, that we cannot yet manifest on demand.

Our challenge is to transform the intermittent bug into a regular bug by resolving the mystery surrounding it. After that it’s the programmer’s headache.

Read more: How to Investigate Intermittent Problems from James Bach's Blog

Bugs also tend to cluster, so figuring this one out, might also catch some other issues. Once it is found you will be rewarded, atleast with a good story others can learn from in the future.

Do try to estimate risks versus effort, maybe instead of pouring in infinite resources, decide how you could prevent or detect it better in the future. Creating better logging and monitoring, hopefully making it easier to solve the mysterie in the future.

One bad request might not be such a big deal, but loss of data that happend once is. Could the bad request lead to a chain of events breaking something else?

Story of data loss:

I once had an loss of data incident that after a short mysterie hunting we called a fluke. We thought it was due to the testing environment using old badly migrated data or something we didn't fully understand. Until we released to production and one of our clients lost the same data. In the end it was cause by a triple click on something where it lost a reference needed for coupling data. When saved the connecting reference would be removed, not just on this save, but on all data.

After it happend in production it took me two full days to reproduce it. Thankfully we had good backup, still next time I would rather spend the two days before releasing it into production.


There are two issues here:

  • Unspecified database commit transaction failure
  • 400 Bad Request when the request was actually fine and problem is on the server side

It is clear what should be an expected result for the first issue.

It is less obvious what should be expected result for the second issue.

400 is a bad error status because, as HTTP 1.1 specs says, this code is when:

The request could not be understood by the server due to malformed syntax.

Michael Durrant suggested to use 404. However, HTTP 1.1 specs suggests that this error is returned when:

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.

Therefore, I would expect 500:

500 Internal Server Error: The server encountered an unexpected condition which prevented it from fulfilling the request.

Some companies do not wish to throw 500 when there's a problem with authentication to avoid giving hints about possible vulunerabilities, but I don't think this is your case.

Regarding your further questions:

How should we deal with bugs like these ? Should we close such bugs because the issue does not occur anymore or demand an investigation ? I'd prefer the latter option though.

I think, the answer Niels van Reijmersdal, explains that pretty well :-)


Work with the maintainer of the API and explain the issues and ask them to adjust the code on their end so that the error generates a 404 return code ('resource not found', applies to any entity for which a request was made but not satisfied) instead of a 400 - Bad Request.

Failing this or a quick response from the maintainer, when you get a 400, check if the body has the "unspecified database commit transaction failure" message and if so treat the error as a 404, resource not available (it applies to more than just pages, hence 'resource') and act accordingly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.