-
Notifications
You must be signed in to change notification settings - Fork 147
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
feat: allow Settings.host
to be used when Settings.servicePath
is set
#1275
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1275 +/- ##
=======================================
Coverage 98.50% 98.50%
=======================================
Files 30 30
Lines 18612 18617 +5
Branches 1431 1431
=======================================
+ Hits 18333 18338 +5
Misses 276 276
Partials 3 3
Continue to review full report at Codecov.
|
@thebrianchen Did you look at why this failed? I don't see how this can fail: nodejs-firestore/dev/src/index.ts Line 427 in 56355f1
unsets the servicePath if FIRESTORE_EMULATOR_HOST is set. nodejs-firestore/dev/src/index.ts Line 496 in 56355f1
|
Settings.host
to override existing host when calling settings()
.
Settings.host
to override existing host when calling settings()
.Settings.host
to override existing host when calling settings()
.
Settings.host
to override existing host when calling settings()
.Settings.host
to override existing host when calling settings()
dev/src/index.ts
Outdated
settings.servicePath !== undefined | ||
? settings.servicePath | ||
: settings.apiEndpoint |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
settings.servicePath !== undefined | |
? settings.servicePath | |
: settings.apiEndpoint | |
settings.servicePath ?? settings.apiEndpoint |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks, done.
dev/src/index.ts
Outdated
(settings.servicePath !== undefined && | ||
settings.servicePath !== settings.host) || | ||
(settings.apiEndpoint !== undefined && | ||
settings.apiEndpoint !== settings.host) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Host is "hostname:port". At least servicePath is just hostname. Can you verify that this works as expected?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed logic to compare hostnames.
delete settings.host; | ||
delete settings.apiEndpoint; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can now delete the code that also does this in the constructor.
By the way, I am still a little uneasy about the order of operations here:
process.env.FIRESTORE_EMULATOR_HOST = 'chicago';
const firestore = new Firestore({host: 'sanfrancisco'});
// Now talking to 'chicago'
vs:
process.env.FIRESTORE_EMULATOR_HOST = 'chicago';
const firestore = new Firestore()
firstore.setting({host: 'sanfrancisco'});
// Now talking to 'sanfrancisco'
Maybe all the constructor code should be moved to validateAndApplySettings
, where we can then use a unified and sane behavior?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
moved the deletion code over to validateAndApplySettings
. However, we need to keep the env var check in the constructor in order to preserve existing behavior where the env var overrides anything passed into the constructor.
dev/src/index.ts
Outdated
// calls `settings()`, which will compare the the provided `host` to the | ||
// existing hostname stored on `servicePath`. | ||
delete settings.host; | ||
delete settings.apiEndpoint; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be moved into the if-statement above, shouldn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch, done.
let url: URL | null = null; | ||
|
||
// If the environment variable is set, it should always take precedence | ||
// over any user passed in settings. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we feel strongly that this is the wrong thing to do, should add a TODO to fix this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how we would fix it without creating an inconvenient breaking change for developers. Since this is only used for emulators and 1p testing, I think the current behavior isn't "wrong". I mainly wanted to document the priority order to make the code easier to understand.
settings.apiEndpoint !== url.hostname) | ||
) { | ||
// eslint-disable-next-line no-console | ||
console.warn( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am debating if it makes sense to log this warning even when FIRESTORE_EMULATOR_HOST is used. Most of the time, this shouldn't warn since servicePath and apiEndpoint are rarely set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think that makes more sense. If anything, it will make it easier for developers to figure out what host is actually being used.
dev/src/index.ts
Outdated
} | ||
|
||
// We need to remove the `host` and `apiEndpoint` setting, in case a user |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment no longer applicable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this still applicable if the user does not provide the env var? In that case, creating a new Firestore with a host passed in and then calling settings()
with host
specified would cause this situation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Please update PR title to match new behavior.
Settings.host
to override existing host when calling settings()
Settings.host
to be used when Settings.servicePath
is set
Fixes #1265.
The existing behavior prioritized
FIRESTORE_EMULATOR_HOST
over any user-specified host when set, and prohibits setting the host more than once. This PR allowsSettings.host
to take precedence overSettings.servicePath
andSettings.apiEndpoint
ifFIRESTORE_EMULATOR_HOST
is not set and logs a warning when the host is overridden. Otherwise,FIRESTORE_EMULATOR_HOST
is used as the host, regardless of any values that are passed viaSettings
.