Support connecting to firestore emulator running on separate container/machine

[rpeach]

From what I can tell the firestore client has to be running on the same machine as the emulator, otherwise you end up with a gRPC error: endpoint is neither UDS or TCP loopback address

This makes running the firestore client and emulator in different docker containers impossible (well not exactly - see the monkeypatch).

The reason that this happens is that the client creates local_credentials which gRPC enforces are only used for connections via the loopback adapter or unix sockets.

Description of my setup:
docker container1: Our app which connects to firestore emulator
docker container2: firestore emulator

Possible solutions:

• Use an insecure channel to talk to the emulator
• Create proper credentials to talk to the emulator

My initial thoughts are: just use insecure channel, it is only the emulator. But that might be missing something.

For anyone seeing this issue and wondering if there is a temporary workaround, I'm using this monkeypatch for our testing setup:

import grpc
from google.cloud.firestore_v1.base_client import BaseClient


def monkey_patch_firestore_emulator():
    def _emulator_channel(self, transport):
        if "GrpcAsyncIOTransport" in str(transport.__name__):
            return grpc.aio.insecure_channel(self._emulator_host)
        else:
            return grpc.insecure_channel(self._emulator_host)

    BaseClient._emulator_channel = _emulator_channel


monkey_patch_firestore_emulator()

[nate-trojian]

Same thing happened for my team. We'd been using the python firebase-admin library for one of our services, and running the emulators in a Docker container for local development and integration tests in our CI/CD pipelines. This change in v2.1.0 broke the local setups and the pipelines. We have strict versioning for all the higher level dependencies, but the firebase-admin library always uses the latest of this library so it didn't matter much.

[jhartquist]

Same thing happened for my team. We'd been using the python firebase-admin library for one of our services, and running the emulators in a Docker container for local development and integration tests in our CI/CD pipelines. This change in v2.1.0 broke the local setups and the pipelines. We have strict versioning for all the higher level dependencies, but the firebase-admin library always uses the latest of this library so it didn't matter much.

Having the same issue. Pinning google-cloud-firestore==2.0.2 for now..

[nate-trojian]

Having the same issue. Pinning google-cloud-firestore==2.0.2 for now..

If you are also using the firebase-admin-python library, make sure you don't update past 4.5.3. Minimum supported version of this library it now supports is the breaking version.
Was updated here: https://github.com/firebase/firebase-admin-python/blob/master/requirements.txt#L10

[craiglabenz]

Thanks for reporting this, @rpeach, especially with the detailed explanation. Since #402, which was released in version 2.2.1, it's possible that the insecure channel used for emulator communication has helped this issue.

Would you mind re-checking your set up against version 2.2.1 and reporting back on your results?

[nate-trojian]

With the change in e28272a, I can confirm this is now working for my project. Unfortunately, this -> #359 (comment) is now the issue blocking me, but I'll post my problems there

[tseaver]

@rpeach Thanks for the report! AFAICT, your usecase should be satisfied by the fix in PR #402. Can you please verify that it works for you as of google-cloud-firestore 2.3.0 or later?

[meredithslota]

I believe the question has been answered so I'm going to close this. :)