-
Notifications
You must be signed in to change notification settings - Fork 939
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
Firestore emulator in deadlock in transaction #2452
Comments
I wonder if there is progress on this issue? It seems about a year ago the problem occurred as well. Maybe this is related? |
Thanks for filing this issue! Filed b/162265825 for internal tracking. |
Could be related yeah. Could this behaviour be changed or is there a way to influence this timeout time? It's not very realistic to let our tests wait for 30 seconds. |
Any update on that @samtstern @rosalyntan ? It's a bit critical because it's making Firestore emulator unusable for any integration tests using transactions. Thanks! |
Any progress on this issue? |
Same problem. |
Same issue here, apparently |
We just ran into this issue too. Looks like we can't use the emulator for logic that has transactions with contention. |
Same here. Relevant part of code looks like this:
In production, there is no problem. In the emulator, it stalls for maybe 30 seconds, and only then it successfully completes. |
Is there any way to prioritize this? I can't deploy code that can't be tested. |
Please, is anyone working on this ? |
It's been a year since the last member comment, how do we prioritize this? @samtstern @avolkovi @rosalyntan @mbleigh @bkendall @joehan @yuchenshi |
If comments / feedback help with prioritization, I'll add that this is a pretty big thorn in our side. We have multiple tests that verify that our transactional logic is resilient to concurrent updates. The emulator consistently pauses for 30 seconds (and sometimes 60 or 90 seconds) for each of these tests. |
My team would also like this issue to be resolved. |
I've spoken with another engineer familiar with the problem. It's not an easy fix to solve this an apparently will take a modest amount of engineering effort to fix completely. The correct team is aware of the bug and has a plan, but prioritization and resourcing hasn't enabled them to address it yet. I can't comment on any expected timeline, but I'll follow up when there's news. Sorry I don't have a better answer at this point. |
It is a relief that this issue is known to be only with the Emulator and not in prod. I was going to turn off the test, deploy to prod, and watch the logs for request durations if I didn't find this thread. Perhaps as a stop-gap, some information can be added to the official documentation? Something like: "Simultaneous requests in a transaction that access the same document may be much slower in the emulator when compared to in production." |
I experience this 30 seconds delay using the Firestore emulator even though my two concurrent transactions do not read the same documents. If I execute the same concurrent transactions using a real firestore DB, it works perfectly fine. When using the emulators, the transactions just won't commit and I don't know why... |
Hey Google, how do you expect us to write proper tests without proper support of transactions...? Wait, did I just hear "test in prod!" ? 😱😱😱 |
We have allocated resource to work on it. |
So I am having the same problem. Hope this gets resolved soon. |
Hope this issue will resolve soon! 😉 |
Environment info
firebase-tools: 8.5.0
Platform: macOS
Node: 10.21.0
Test case
When reading/writing to a document using two simultaneous transactions, the transactions hang (as if in a deadlock).
I added some sample code to illustrate the problem (including some console logs to clarify where the code hangs).
firestore-emulator-bug-showcase.zip
Steps to reproduce
After downloading the sample code run:
npm install firebase emulators:start --only firestore --debug # Assuming to be at version 8.5.0
While the emulator runs, run the following command in a different terminal:
npm run test
Expected behavior
I would expect all tests to run successfully. This means:
true
is returned.true
while the other returnsfalse
.Actual behavior
But actually the 'lease multi' test hangs and times out. The 'firestore' and 'lease single' tests run as expected.
See the output below:
Output of jest:
Output of the emulator:
The text was updated successfully, but these errors were encountered: