Open kris-kolve-jumio opened 1 year ago
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
@jbalidiong I finished updating the ticket. Sorry for the delay.
Any updates on the issue?
@YehorPytomets I haven't heard anything but I have played around some more...
I tried moving to Jest. and interestingly with Jest 27.x I can get it to work as expected!
Jest 28/29.x I get the same issue. where uploads never resolve. So far I have been able to deduce that it has something to do with what libraries are injected when no browser is actually present. I think firebase Storage API is complicated by the fact that it relies on the GCP storage library. But this is out of my wheelhouse. Hopefully that makes some sense.
Thank you @kris-kolve-jumio.
I was able to play around with this and fixed the upload issue by changing the storage
host from localhost
to 127.0.0.1
. I use Mocha ^10.2.0
.
@kris-kolve-jumio I can confirm similar issue that jest 27 works but 28 and 29 do not. Also @YehorPytomets suggestion of switching to Mocha instead of jest did the trick for me. I could not use jest27 because I was using more bleeding-edge esm features that jest27 was too old for
Hello, any updates on this? The issue is still relevant even with @firebase/rules-unit-testing@3.0.2
. We have had to split our tests to ones without uploads running on vitest
with the rest stuck on jest@27.5.1
.
It seems like the uploadBytes
function gets stuck after it opens a connection to the emulators. The logs do not contain any information about the upload until vitest
stops the test after timeout. This is the only log that gets printed:
BadRequestError: request aborted
at IncomingMessage.onAborted (/.../node_modules/raw-body/index.js:245:10)
at IncomingMessage.emit (node:events:514:28)
at IncomingMessage.emit (node:domain:489:12)
at IncomingMessage._destroy (node:_http_incoming:224:10)
at _destroy (node:internal/streams/destroy:109:10)
at IncomingMessage.destroy (node:internal/streams/destroy:71:5)
at abortIncoming (node:_http_server:782:9)
at socketOnClose (node:_http_server:776:3)
at Socket.emit (node:events:526:35)
at Socket.emit (node:domain:489:12)
Running the upload with uploadBytesResumable
returns only a single running
snapshot that reports bytesTransfered
as 0
.
Security rules seem to have no effect - if I disable them all, the result of the upload is still the same.
[REQUIRED] Describe your environment
[REQUIRED] Describe the problem
uploadBytes and uploadString storage functions do not resolve when using the @firebase/rules-unit-testing library. This causes the test to timeout even at 20+seconds.
This occurs with authenticatedContext, and unauthenticated contexts.
It is also worth noting that, getBytes, and getDownloadURL, resolve as expected.
I get the same results using Mocha and Jest. I have even tried the v8 SDK with the same results.
I did not have the upload issue when using the Admin SDK with the emulators. I have not tried it yet in my app but suspect it will work as desired.
Steps to reproduce:
Result: upload promise will never resolve.
Expected Result: upload promise resolves well within a second and the test will fail (assuming the rules prevent uploads from unauthenticated users.
If I do not set the hub host to "127.0.0.1" I will get an ECCONREFUSED ::1:4400. Also interesting and possibly related:
1) Setting the hub:{host:"127.0.0.1", port:4400} does not make storage discoverable and also does not throw an ECCONREFUSED ::1. However, it does make it so the getBytes test ends up throwing a "FirebaseError: Firebase Storage: Max retry time for operation exceeded"
2) Setting the storage:{host:"127.0.0.1", port:9199} seems to make the storage discoverable. getBytes will resolve but uploadBytes will never resolve... I wonder if the host configuration is not propagating to post commands sent to the emulators? IDK.
Relevant Code:
storage.rules -
Note: it is necessary to add type:'module' in the package file so that imports work.
index.spec.js - TEST FILE