Skip to content
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

Bug 1649926 - Always enqueue an async task to change upload and deprecate getUploadEnabled #1046

Merged
merged 12 commits into from
Jul 22, 2020

Conversation

badboy
Copy link
Member

@badboy badboy commented Jul 9, 2020

Replicating the commit messages for information:

Always enqueue an async task to change upload

That way it follows what a user expect when calling it in between other calls:
It executes in the right order.

Because the dispatch queue is halted until Glean is fully initialized
we can safely enqueue here and it will execute after initialization.

and

Deprecate `getUploadEnabled()` across all implementations

Due to Glean's asynchronous initialization the return value can be incorrect.
Applications should not rely on Glean's internal state.
Upload enabled status should be tracked by the application and communicated to Glean if it changes.
Note: The method was removed from the C# implementation.

This probably deserves some extra eyes on it. Putting you 3 on it, but maybe one or 2 should be enough.

I'm now reasonably sure it does what we expect it to do and the tests capture that.
However the tests are a bit brittle and (at least in some cases) might pass just fine on the old code base too.

Getting rid of getUploadEnabled means we also don't need to additionally track that upload enabled flag anymore.

Unfortunately I can't write a C# test because we don't have all the necessary utilities in place yet.
I did verify that adding GleanInstance.SetUploadEnabled(false); in the sample app just after Initialize does NOT send the custom ping, but DOES send the deletion-request ping.

@badboy badboy requested review from mdboom, Dexterp37 and travis79 July 9, 2020 14:44
@auto-assign auto-assign bot requested a review from brizental July 9, 2020 14:45
Copy link
Member

@travis79 travis79 left a comment

Choose a reason for hiding this comment

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

I'd say this approach looks good to me (provided the iOS tests pass, which I assume they do). The one problem I see is that Lockwise-iOS does rely on getUploadEnabled in a weird way, that can be fixed if they ever update Glean.

Copy link
Contributor

@mdboom mdboom left a comment

Choose a reason for hiding this comment

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

What happens in the following order of events?

Glean.setUploadEnabled(false)
Glean.initialize(uploadEnabled=true)

I would expect the state to be upload is enabled, but since the first call would be deferred until after the second, that might not happen (we should confirm with a test -- I could be wrong).

glean-core/python/glean/glean.py Show resolved Hide resolved
// data after the upload has been disabled.
PingUploadWorker.cancel(applicationContext)
}
// Changing upload enabled always happens asynchronous.
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure if it's important to call out or not somewhere, but consider this scenario:

  1. Initialize(uploadEnabled: true) is called
  2. somePing.submit() is called right after
  3. SetUploadEnabled(false) is called.

The ping at (2) might still get through, and I believe it's fine-ish. What do you think @badboy ?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, that's the behavior I would expect. From a user perspective uploadEnabled was set to false only after the ping was submitted.

However ... (gosh this is complicated) ... because of the delay of the uploader picking it up it could still get cancelled :/

glean-core/csharp/Glean/Glean.cs Outdated Show resolved Hide resolved
glean-core/ios/Glean/Glean.swift Outdated Show resolved Hide resolved
glean-core/csharp/Glean/Glean.cs Outdated Show resolved Hide resolved
glean-core/python/glean/glean.py Outdated Show resolved Hide resolved
glean-core/python/glean/glean.py Outdated Show resolved Hide resolved
@badboy
Copy link
Member Author

badboy commented Jul 10, 2020

What happens in the following order of events?

Glean.setUploadEnabled(false)
Glean.initialize(uploadEnabled=true)

I would expect the state to be upload is enabled, but since the first call would be deferred until after the second, that might not happen (we should confirm with a test -- I could be wrong).

Damn, you are probably right. This is the one case why we had to preserve the state in an instance variable.
I need to think about it.

@badboy
Copy link
Member Author

badboy commented Jul 10, 2020

Ok, following up on what Mike said.

The positive first: It's easy to write a test!
Now the rest:
I think the only sensible solution is to actually ignore setUploadEnabled completely before Glean is initialized.
If that happens the order is (mostly) clear and the initialize should be the last operation, so is what should take precedence.
We already expect the uploadEnabled passed to initialize be correct. The whole reason we introduce that parameter was because people kept doing it wrong with setUploadEnabled.

I propose we add this to the top of setUploadEnabled:

        if (!isInitialized()) {
            Log.w(LOG_TAG, "Changing upload enabled before Glean is initialized is not supported.")
            return
        }

cc @Dexterp37 @mdboom

@badboy
Copy link
Member Author

badboy commented Jul 10, 2020

I spoke too soon.

We can't differentiate between

Glean.setUploadEnabled(false)
Glean.initialize(...)

and

Glean.initialize(...)
Glean.setUploadEnabled(false)

right now.

Do we really need more state? -_-

@badboy
Copy link
Member Author

badboy commented Jul 10, 2020

So yeah, if we track that initialize was called at all we might be able to prevent this properly.

wdyt?

@Dexterp37
Copy link
Contributor

I propose we add this to the top of setUploadEnabled:

        if (!isInitialized()) {
            Log.w(LOG_TAG, "Changing upload enabled before Glean is initialized is not supported.")
            return
        }

cc @Dexterp37 @mdboom

I support this approach and like it. My only recommendation would be to have a more comprehensive message or add a link to our docs that explain the initial state should be provided with Glean.Initialize.

@badboy
Copy link
Member Author

badboy commented Jul 10, 2020

As I won't get this done today here's what's left:

  • Incorporate the comments from above
    • true -> false in getUploadEnabled across all implementations
    • In Python make getUploadEnabled private
  • Add a new variable initWasCalled (name bikesheddable), set to true before returning from initialize
  • Check that new variable in setUploadEnabled
    • Print warning with extended message if initWasCalled == false

Copy link
Contributor

@Dexterp37 Dexterp37 left a comment

Choose a reason for hiding this comment

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

r+ with a few optional nits! Great work on this one, thanks for your efforts. Please DO NOT MERGE just yet. I'd love to cut a release before this gets merged :)

glean-core/csharp/Glean/Glean.cs Outdated Show resolved Hide resolved
glean-core/ios/Glean/Glean.swift Outdated Show resolved Hide resolved
glean-core/python/glean/glean.py Outdated Show resolved Hide resolved
@badboy badboy force-pushed the deprecate-getuploadenabled branch from e9e7154 to ba80541 Compare July 22, 2020 08:24
@badboy
Copy link
Member Author

badboy commented Jul 22, 2020

Waiting with the rebase, given that there's a release incoming and thus I need to change the changelog anyway.

@badboy badboy force-pushed the deprecate-getuploadenabled branch from ba80541 to ca7d46f Compare July 22, 2020 08:57
badboy added 7 commits July 22, 2020 11:06
That way it follows what a user expect when calling it inbetween other calls:
It executes in the right order.

Because the dispatch queue is halted until Glean is fully initialized
we can safely enqueue here and it will execute after initialization.
Due to Glean's asynchronous initialization the return value can be incorrect.
Applications should not rely on Glean's internal state.
Upload enabled status should be tracked by the application and communicated to Glean if it changes.
Note: The method was removed from the C# implementation.
badboy and others added 5 commits July 22, 2020 11:06
After we destroy the Glean handle we should be conceptually in a clean
state, just as if the app is just starting and loading Glean.

And for Glean that means tasks should get queued up.
Some tests explicitly toggle this already, but resetting it here does
not seem to affect them.
Co-authored-by: Alessio Placitelli <alessio.placitelli@gmail.com>
@badboy badboy force-pushed the deprecate-getuploadenabled branch from ca7d46f to 2717a62 Compare July 22, 2020 09:06
@badboy badboy merged commit 44dd079 into main Jul 22, 2020
@badboy badboy deleted the deprecate-getuploadenabled branch July 22, 2020 09:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants