Skip to content

Conversation

ryanwilson
Copy link
Member

@ryanwilson ryanwilson commented Apr 14, 2021

This should mitigate heartbeat files being wiped due to tvOS cache being
invalidated. Fixes #6662

#no-changelog

Package.swift Outdated
"7.2.1" ..< "8.0.0"
// TODO: Move from `revision` to version below before publishing.
.revision("a59fd0181d8f7c2b4c815cd6cddf4c38a4ba35ee")
// "7.4.0" ..< "8.0.0"
Copy link
Member Author

Choose a reason for hiding this comment

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

This tag won't be available until we publish GoogleUtilities.

Copy link
Member Author

Choose a reason for hiding this comment

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

cc @paulb777 - how did we handle this in the past?

Copy link
Member

Choose a reason for hiding this comment

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

We either need to publish GoogleUtilities sooner or update this later in the release cycle.

There are some options to explore from https://forums.swift.org/t/best-practices-for-integration-testing-and-releasing-multiple-packages/47006/11, but nothing too clear or easy.

Copy link
Member Author

Choose a reason for hiding this comment

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

Happy to hold off temporarily and cherry-pick this when it's published. We should also probably set up a presubmit that prevents .revision from being checked in to prevent failures in the future

NSString *const kHeartbeatStorageName = @"HEARTBEAT_INFO_STORAGE";
id<GULHeartbeatDateStorable> dataStorage;
#if TARGET_OS_TV
NSString *const kFIRCoreSuiteName = @"com.firebase.core";
Copy link
Member Author

Choose a reason for hiding this comment

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

I can stick with standardUserDefaults but felt like I should move away from it. Thoughts on this domain?

Copy link
Contributor

Choose a reason for hiding this comment

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

A custom domain looks reasonable as there is less probability that it will be modified by developers for their purposes. "com.firebase.core" is pretty generic name, so I would either declare a more specific one for the heartbeat use only or at least define a constant available for the rest of Core if we would like to reuse the same defaults for other purposes. I would prefer the more specific name.

Copy link
Member Author

Choose a reason for hiding this comment

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

I did intentionally name it so Core could use it in the future for other things, since I don't think we need a new suite name for every piece of data we need to store (that's what the keys are for). Breaking it out into a constant would make sense in that case then, and other SDKs could follow suit eventually (com.firebase.auth, .firestore, etc).

Does that sound reasonable?

Copy link
Contributor

@maksymmalyhin maksymmalyhin Apr 14, 2021

Choose a reason for hiding this comment

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

SGTM. The only potential issue with reuse may be that the same defaults may potentially be modified from different parts of the code that may be easy to overlook. It seems to me that having extra user defaults is a relatively cheap mitigation of this issue. I'm fine with either for this PR.

Copy link
Member Author

@ryanwilson ryanwilson Apr 14, 2021

Choose a reason for hiding this comment

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

Yeah, we currently use a single user defaults (standardUserDefaults) anyways so this wouldn't be anything new, and we should provide a unique key for each usage point as we currently do.

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah, makes sense. Looks safe for now.

@ryanwilson ryanwilson added this to the 7.11.0 - M94 milestone Apr 14, 2021
Copy link
Contributor

@maksymmalyhin maksymmalyhin left a comment

Choose a reason for hiding this comment

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

LGTM

NSString *const kHeartbeatStorageName = @"HEARTBEAT_INFO_STORAGE";
id<GULHeartbeatDateStorable> dataStorage;
#if TARGET_OS_TV
NSString *const kFIRCoreSuiteName = @"com.firebase.core";
Copy link
Contributor

Choose a reason for hiding this comment

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

A custom domain looks reasonable as there is less probability that it will be modified by developers for their purposes. "com.firebase.core" is pretty generic name, so I would either declare a more specific one for the heartbeat use only or at least define a constant available for the rest of Core if we would like to reuse the same defaults for other purposes. I would prefer the more specific name.

@ryanwilson
Copy link
Member Author

Will wait until GoogleUtilities 7.4.0 publishes so we can have the proper Package.swift land here, then I'll merge. Thanks for the reviews!

@google-oss-bot
Copy link

google-oss-bot commented Apr 14, 2021

Coverage Report

Affected SDKs

  • FirebaseFirestore-iOS-FirebaseFirestore.framework

    SDK overall coverage did not change between base commit (d937b2f) and head commit (dd6c93c). However there are changes in individual files.

    Filename Base (d937b2f) Head (dd6c93c) Diff
    exception.cc 65.85% 29.27% -36.59%
    leveldb_key.cc 96.79% 98.39% +1.61%
    ordered_code.cc 93.24% 93.80% +0.56%
    task.cc 95.21% 97.60% +2.40%
    write_stream.cc 95.65% 93.48% -2.17%

Test Logs

@paulb777 paulb777 modified the milestones: 7.11.0 - M94, 8.0.0 - M95 Apr 16, 2021
@paulb777
Copy link
Member

I moved the milestone to 8.0.0 since the update did not make it into 7.11.0.

@ncooke3
Copy link
Member

ncooke3 commented Apr 27, 2021

Kicked off a rerun of CI to test with GoogleUtils 7.4 (that is staged in SpecsStaging atm)

This should mitigate heartbeat files being wiped due to tvOS cache being
invalidated.
@ncooke3 ncooke3 force-pushed the rw-heartbeat-userdefaults branch from 5907aa6 to b879789 Compare April 27, 2021 16:14
@ncooke3 ncooke3 requested a review from paulb777 April 27, 2021 17:42
name: "GoogleUtilities",
url: "https://github.com/google/GoogleUtilities.git",
"7.3.0" ..< "8.0.0"
"7.4.0" ..< "8.0.0"
Copy link
Member

@ncooke3 ncooke3 Apr 27, 2021

Choose a reason for hiding this comment

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

@paulb777 @ryanwilson tagged GoogleUtils 7.4.0 for SwiftPM (on GoogleUtils repo) and am now pointing to GoogleUtils 7.4 in the Package manifest here.

Copy link
Member Author

@ryanwilson ryanwilson left a comment

Choose a reason for hiding this comment

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

LGTM - thanks for the update!

@ncooke3 ncooke3 merged commit 84a2a2c into master Apr 27, 2021
@ncooke3 ncooke3 deleted the rw-heartbeat-userdefaults branch April 27, 2021 19:19
@firebase firebase locked and limited conversation to collaborators May 28, 2021
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.

GULHeartbeatStorage: use user defaults instead of a file on tvOS
5 participants