fix: Force http in the GAX module when using the GAX fallback and connecting to the emulator

[MarkDuckworth]

fix: Force http in the GAX module when using the GAX fallback and connecting to the emulator

[conventional-commit-lint-gcf]

🤖 I detect that the PR title and the commit message differ and there's only one commit. To use the PR title for the commit history, you can use Github's automerge feature with squashing, or use automerge label. Good luck human!

-- conventional-commit-lint bot
https://conventionalcommits.org/

[dconeybe]

Can you think about how you might write a unit or integration test for this? My first, probably dumb, idea is to spin up a local http server and try to connect to it and make sure the connection is done via http (and not https). Just something to think about, if you can find a practical way to test this. Maybe there is somewhere else you can "hook in" to make sure the correct protocol is used.

[alexander-fenster]

LGTM but would prefer having a well defined type if possible.

[MarkDuckworth]

Can you think about how you might write a unit or integration test for this? My first, probably dumb, idea is to spin up a local http server and try to connect to it and make sure the connection is done via http (and not https). Just something to think about, if you can find a practical way to test this. Maybe there is somewhere else you can "hook in" to make sure the correct protocol is used.

@dconeybe I think the best solution will be to configure all integration tests to run against the emulator. I'll touch base with the team on this and align with strategy for running against emulator vs production database.

[dconeybe]

Can you think about how you might write a unit or integration test for this? My first, probably dumb, idea is to spin up a local http server and try to connect to it and make sure the connection is done via http (and not https). Just something to think about, if you can find a practical way to test this. Maybe there is somewhere else you can "hook in" to make sure the correct protocol is used.

@dconeybe I think the best solution will be to configure all integration tests to run against the emulator. I'll touch base with the team on this and align with strategy for running against emulator vs production database.

But then the scenario where the emulator is not used is left untested. I definitely wouldn't block merging this PR on switching the tests to run against the Firestore emulator. But is there some way that you can write unit tests for the settings that get passed into new module.exports.v1(settings, gax)? It looks like it may be somewhat challenging, but it would be good to add such tests to avoid backsliding. Maybe just try it out to see if it's easy and timebox the work. If it ends up being unwieldy, then don't worry about it.