Skip to content

Unified emulator settings for Database #1672

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

Merged
merged 18 commits into from
Jun 19, 2020
Merged

Unified emulator settings for Database #1672

merged 18 commits into from
Jun 19, 2020

Conversation

samtstern
Copy link
Contributor

@samtstern samtstern commented Jun 17, 2020

This is the first PR for http://go/firebase-emulator-connection-api

This implements the global changes needed in FirebaseApp as well as the changes in FirebaseDatabase to support them.

TODO:

  • Properly hide the FirebaseApp changes so that this doesn't leak before Functions / Firestore are implemented.

@google-oss-bot
Copy link
Contributor

google-oss-bot commented Jun 17, 2020

Binary Size Report

Affected SDKs

  • firebase-common

    Type Base (a7096ac) Head (2a276c10) Diff
    aar 34.3 kB 37.6 kB +3.28 kB (+9.6%)
  • firebase-database

    Type Base (a7096ac) Head (2a276c10) Diff
    aar 481 kB 482 kB +451 B (+0.1%)

Test Logs

Notes

Head commit (2a276c10) is created by Prow via merging commits: a7096ac b072f54.

@google-oss-bot
Copy link
Contributor

The public api surface has changed for the subproject firebase-common:
error: Added method com.google.firebase.FirebaseApp.enableEmulators(com.google.firebase.emulators.EmulatorSettings) [AddedMethod]
error: Added method com.google.firebase.FirebaseApp.getEmulatorSettings() [AddedMethod]
error: Added package com.google.firebase.emulators [AddedPackage]

Please update the api.txt files for the subprojects being affected by this change by running ./gradlew ${subproject}:generateApiTxtFile. Also perform a major/minor bump accordingly.

@google-oss-bot
Copy link
Contributor

google-oss-bot commented Jun 17, 2020

Coverage Report

Affected SDKs

  • firebase-common

    SDK overall coverage changed from 44.86% (a7096ac) to 43.41% (2a276c10) by -1.45%.

    Filename Base (a7096ac) Head (2a276c10) Diff
    EmulatedServiceSettings.java ? 0.00% ?
    EmulatorSettings.java ? 46.67% ?
    FirebaseApp.java 52.97% 51.42% -1.56%
    FirebaseEmulator.java ? 0.00% ?
  • firebase-database

    SDK overall coverage changed from 51.22% (a7096ac) to 51.19% (2a276c10) by -0.04%.

    Filename Base (a7096ac) Head (2a276c10) Diff
    BooleanNode.java 100.00% 92.31% -7.69%
    ChildChangeAccumulator.java 96.77% 83.87% -12.90%
    FirebaseDatabase.java 30.14% 32.00% +1.86%
    Utilities.java 68.99% 69.92% +0.93%
    ViewProcessor.java 92.35% 92.05% -0.31%

Test Logs

Notes

HTML coverage reports can be produced locally with ./gradlew <product>:checkCoverage.
Report files are located at <product-build-dir>/reports/jacoco/.

Head commit (2a276c10) is created by Prow via merging commits: a7096ac b072f54.

@samtstern samtstern marked this pull request as ready for review June 17, 2020 16:24
Copy link
Member

@vkryachko vkryachko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am wondering whether EmulatedServiceSettings in firebase-common. Wouldn't it make sense to create a dedicated library for it?
The overhead of adding+launching a new library is pretty low these days. wdyt?

@samtstern
Copy link
Contributor Author

@vkryachko well common will always have to depend on these emulator classes and they are useless outside of common so I don't see a reason to break them out. They're just tiny data classes they won't gain any actual functionality.

@KeepForSdk
public void enableEmulators(@NonNull EmulatorSettings emulatorSettings) {
checkNotDeleted();
Preconditions.checkState(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How will this interact with firestore's terminate()? afaicr one can terminate one instance of firestore at which point the call to FirebaseFirestore#getInstance() will create a new firestore instance, should we allow the following sequence of calls?

firestore.terminate();
app.updateFirestoresEmulator();
Firebase.firestore.use();

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for calling this out, I resolved all the other comments since they were straightforward but I will have to look into this one more deeply.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok actually I do not want to allow that sequence of calls. One of the main reasons for this is to make sure that app developers can reason about their emulation settings at a single point before any Firebase service has done any communication.

If you call terminate() the settings should still apply. If you want to nuke them you'll need to call FirebaseApp#delete() and then make a new app.

WDYT?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point and sgtm. You may want to confirm this behavior with firestore folks though

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do during the Firestore PR.

Copy link
Contributor

@schmidt-sebastian schmidt-sebastian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope you have some sort of copy/paste text snippet that you can use to rebuke all my comments :)

if (serviceSettings != null) {
repoInfo.secure = false;
repoInfo.host = serviceSettings.host + ":" + serviceSettings.port;
repoInfo.internalHost = repoInfo.host;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add an explicit way to decide which credentials to use? I am asking because of Yuchen's feedback here: firebase/firebase-js-sdk#3228

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do think that would be a nice addition one day but this API was approved cross-platform for Android, iOS, and JS without any mention of a credentials setting so I think I'd need to do a new API review for that.

Do you anticipate bugs like that JS one in this implementation?

Copy link
Member

@yuchenshi yuchenshi Jun 18, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be low risk since Android SDK is not reused in Admin SDKs. The expected behavior is the same as production -- get credentials from Firebase Auth if used and logged in, or no credentials if not.

@samtstern samtstern removed their assignment Jun 18, 2020
@samtstern
Copy link
Contributor Author

@schmidt-sebastian all of your comments were about the FirebaseApp stuff (and they were useful!) but I added you as a database reviewer.

  1. Is there anyone else I should add?
  2. Do you have any concerns about the database stuff?

@samtstern samtstern requested a review from vkryachko June 19, 2020 12:54
@@ -110,6 +111,9 @@
private final FirebaseOptions options;
private final ComponentRuntime componentRuntime;

private final AtomicBoolean emulatorSettingsFrozen = new AtomicBoolean(false);
private EmulatorSettings emulatorSettings = EmulatorSettings.getDefault();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: now that settings are immutable, consider sharing the default instance across app instances.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah yeah good call!

Copy link
Member

@vkryachko vkryachko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM overall, a few minor comments

@samtstern samtstern requested a review from vkryachko June 19, 2020 13:43
Copy link
Member

@vkryachko vkryachko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with one final getter nit

@google-oss-bot
Copy link
Contributor

@samtstern: The following test failed, say /retest to rerun them all:

Test name Commit Details Rerun command
device-check-changed b072f54 link /test device-check-changed

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@samtstern
Copy link
Contributor Author

12: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':firebase-firestore:firebase-test-labUpload'.
> Process 'command 'gcloud'' finished with non-zero exit value 10

That's unrelated and this PR was previously green, so gonna merge anyway.

@samtstern samtstern merged commit 5e5111b into master Jun 19, 2020
@samtstern samtstern mentioned this pull request Jun 24, 2020
2 tasks
@firebase firebase locked and limited conversation to collaborators Jul 20, 2020
@kaibolay kaibolay deleted the ss-emulator-settings branch September 14, 2022 17:55
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants