This repository has been archived by the owner on Dec 15, 2022. It is now read-only.
empty all queues in reporterProxy
once data has been sent.
#1659
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of the Change
Recently, I was working on some improvements to the
welcome
package in atom/welcome#67. I noticed that thewelcome
package, which also consumes thereporter
service, empties all queues after the reporter has been set. I believe the queues are emptied to guard against the possibility of the queued data being sent again if the reporter service is re-set.This change empties the queues in the github package's
ReporterProxy
after data has been sent. This change also adds unit tests to verify this new functionality works as expected.Alternate Designs
Is re-sending the same data actually something we need to worry about?
I tried to reproduce a situation where data might be re-sent to see if this is really a problem. I put a
setTimeout
in themetrics
package so that it loads in a deferred fashion, and performed some actions that are instrumented (staging and unstaging changes). This adds data to the queues before the reporter has been set. It appears that a newReporterProxy
class is created in memory each time Atom reloads, so old events sticking around isn't a problem. However, I'm not super confident that I'm testing this in the same conditions that would occur in the wild. Clearing the queues is a simple enough change that I'd just rather do this and put any lingering worries to rest about the accuracy of our data.Benefits
Guard against the possibility that we are re-sending data that has already been sent, which keeps our metrics accurate.
Possible Drawbacks
I can't think of any but am open to feedback.