-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Empty results from MongoDB Atlas (no document returned) #131
Comments
Okay so I did some research and here's my recap:
If like me this issue has caught you off guard and is ruining production code, a simple workaround is to use MongoDB Atlas Data API feature to read from there. It's a band-aid at most but it keeps the boat afloat. |
@KovaxG Can you confirm it's the same issue you're seeing? |
From my perspective, a week ago I could insert and query data normally. A few days ago I noticed that my queries return empty lists all the time. Inserts work normally, I have confirmed this by looking up the collections in atlas. |
I've set up a small testing repository: https://github.com/why-not-try-calmer/test-mongo Alex Bevilacqua from MongoDB has accepted to help troubleshoot this issue. Will keep you posted. |
To keep everyone updated it appears this behavior only affects shared/free tier Atlas clusters (M0/M2/M5). The reproduction @why-not-try-calmer shared does not fail on an M10 or above, so we can at least narrow the scope of this issue to any plumbing that sits between your Haskell applications and the cluster (such as a proxy). Note this would be Atlas infrastructure; nothing you've outright configured yourself ;) Short term, if you upgrade to an M10+ this issue should no longer impact your applications; however this may not be ideal in all scenarios as there is a cost associated with the upgrade. I'll keep this issue updated as more information surfaces, however I wanted to share an update in the meantime. |
Thank you for the update! I am happy about the narrowing-down. I think the main worry here is that a library is supposed to treat all consumers equally, and this can no longer be guaranteed if the library fails for consumers using <M10 Atlas clusters. :-) Please let us know if there's anything more we can do to help troubleshoot the issue. |
@VictorDenisov Just pinging you to know if you're following the situation here. Also to know: if in the next weeks a fix can be produced, how much time does it need before it hits Hackage once the PR is accepted? (I believe my previous merged PR, months ago, has not hit Hackage yet) |
It's only a matter of how soon you need it in Hackage. |
Okay, thank you very much for you reply! We're trying to narrow down on the culprit and this is likely to trigger some small updates to the library along the way from me, even if we don't manage to put our finger on the exact culprit. I'd like to finish with this before PR-ing transactions, otherwise the testing will be god awful. |
Just to provide an update to anyone watching this ticket. We believe we've found the issue and fixing it will not require any changes to the Haskell driver. Once this has been actioned I'll share more information. |
That's amazing! Please share as many crispy details as you're allowed to, it's been a true Netflix show! |
TL;DR is it looks like a bug was introduced as a result of a proxy update to make Once this is all sorted out I hope to write something up about it so I'll make sure I share that here as well :) |
Cool! I will still make a PR to improve our handshake and get closer to compliance with the protocol/interface that you guys expect. |
I would like to rule out my team being affected by this issue for some slightly different causes, is there some workaround while you work on a PR I could try? |
@codygman if you are connecting to an M0/M2/M5 cluster the issue may affect you. Upgrading to an M10 would address the issue until further fixes are implemented. If you're already on an M10+ cluster tier (in Atlas) the issue wouldn't affect you. The same would go for self-managed clusters (not using Atlas) |
I worked around this using the Mongo Data API. |
Second to last update - the MongoDB team has identified the issue, has a patch and is currently testing it. Once this has been released any Haskell applications that were affected by this issue should start working again. No client-side updates will be required. Once I know this has been released to production I'll post here so we can close this out. |
Final update - this issue has now been resolved for any MongoDB Atlas M0/M2/M5 deployment. No changes are required in your apps and they should now return results as expected. This should only be considered a temporary fix as legacy opcodes have been removed in MongoDB 6.0. To ensure the Haskell driver continues to work with 6.0 and beyond issue #123 needs to be implemented. For anyone curious as to what the actual issue was and how it was addressed I've written up the diagnostic journey that this bug took us on at https://www.alexbevi.com/blog/2022/09/21/bug-hunting-with-the-mongodb-haskell-community/. |
I really hope this is unrelated to #130 (edit: ah apparently it's not since stackage does not provide the version implementing the PR yet) but after switching to Mongo Atlas for a side project I started facing outstanding issues for reading data from a Cursor (writing and all the rest is fine though). Consider the last few lines in the snippet below:
Any idea what could have gone wrong?
The text was updated successfully, but these errors were encountered: