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
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.