-
Notifications
You must be signed in to change notification settings - Fork 123
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 1656934 - Scan pending pings directories after dealing with upload status #1205
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -187,7 +187,7 @@ impl Glean { | |
/// | ||
/// Importantly, this will not send any pings at startup, since that | ||
/// sort of management should only happen in the main process. | ||
pub fn new_for_subprocess(cfg: &Configuration) -> Result<Self> { | ||
pub fn new_for_subprocess(cfg: &Configuration, scan_directories: bool) -> Result<Self> { | ||
log::info!("Creating new Glean v{}", GLEAN_VERSION); | ||
|
||
let application_id = sanitize_application_id(&cfg.application_id); | ||
|
@@ -201,12 +201,17 @@ impl Glean { | |
let event_data_store = EventDatabase::new(&cfg.data_path)?; | ||
|
||
// Create an upload manager with rate limiting of 10 pings every 60 seconds. | ||
let mut upload_manager = | ||
PingUploadManager::new(&cfg.data_path, &cfg.language_binding_name, false); | ||
let mut upload_manager = PingUploadManager::new(&cfg.data_path, &cfg.language_binding_name); | ||
upload_manager.set_rate_limiter( | ||
/* seconds per interval */ 60, /* max tasks per interval */ 15, | ||
); | ||
|
||
// We only scan the pending ping sdirectories when calling this from a subprocess, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oops: |
||
// when calling this from ::new we need to scan the directories after dealing with the upload state. | ||
if scan_directories { | ||
let _scanning_thread = upload_manager.scan_pending_pings_directories(); | ||
} | ||
|
||
Ok(Self { | ||
upload_enabled: cfg.upload_enabled, | ||
data_store, | ||
|
@@ -230,7 +235,7 @@ impl Glean { | |
/// This will create the necessary directories and files in `data_path`. | ||
/// This will also initialize the core metrics. | ||
pub fn new(cfg: Configuration) -> Result<Self> { | ||
let mut glean = Self::new_for_subprocess(&cfg)?; | ||
let mut glean = Self::new_for_subprocess(&cfg, false)?; | ||
|
||
// The upload enabled flag may have changed since the last run, for | ||
// example by the changing of a config file. | ||
|
@@ -263,6 +268,12 @@ impl Glean { | |
} | ||
} | ||
|
||
// We only scan the pendings pings directories **after** dealing with the upload state. | ||
// If upload is disabled, we delete all pending pings files | ||
// and we need to do that **before** scanning the pending pings folder | ||
// to ensure we don't enqueue pings before their files are deleted. | ||
let _scanning_thread = glean.upload_manager.scan_pending_pings_directories(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Eugh. So this was an actual bug and not a test error. We should add a changelog entry. Do we have any way to estimate how frequently we sent pings out? I'd suspect that's not super frequent, but it's important to better understand. We could also draft a PSA email, if we find the impact being big. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Hm, I need to think about this. When we have this bug it is usually followed by an error on deleting the ping file. Because we send the request to the caller -> it uploads succesfully (usually) -> and then it tries to delete an already deleted file, which logs an error. But that is all we have, from what I remember on the top of my head. I'll think a bit further, if you have any ideas, let me know. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have an idea to validate this: check if any pings are sent from a client_id after this client_id sent a deletion-request ping. Will come back to this thread with results when I have them. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
|
||
Ok(glean) | ||
} | ||
|
||
|
@@ -285,8 +296,7 @@ impl Glean { | |
let mut glean = Self::new(cfg).unwrap(); | ||
|
||
// Disable all upload manager policies for testing | ||
// and make the upload manager scan the pings directories synchronously. | ||
glean.upload_manager = PingUploadManager::no_policy(data_path, true); | ||
glean.upload_manager = PingUploadManager::no_policy(data_path); | ||
|
||
glean | ||
} | ||
|
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.
Having this makes me question the name of this function. If you have better ideas I'd be up for changing it.