Tests relying on reqwest::Client may fail with "dispatch task is gone: runtime dropped the dispatch task" #3852

Activity

1. rami3l

   added

   bug

   on Jun 2, 2024
2. rami3l

   added this to the 1.28.0 milestone on Jun 2, 2024
3. rami3l

   changed the title [-]`suite::cli_exact::check_updates_with_update` failed with "dispatch task is gone: runtime dropped the dispatch task"[/-] [+]Tests relying on `reqwest::Client` may fail with "dispatch task is gone: runtime dropped the dispatch task"[/+] on Jun 4, 2024
4. rami3l commented on Jun 4, 2024

   

   rami3l

   on Jun 4, 2024

   MemberAuthor

   More actions

   According to the error message format and my IDE searching the current codebase, this is a RustupError::DownloadingFile. This kind error message can only be emitted from here:

   rustup/src/utils/utils.rs

   Lines 154 to 190 in 6d43761

   	pub(crate) async fn download_file_with_resume(
   	url: &Url,
   	path: &Path,
   	hasher: Option<&mut Sha256>,
   	resume_from_partial: bool,
   	notify_handler: &dyn Fn(Notification<'_>),
   	) -> Result<()> {
   	use download::DownloadError as DEK;
   	match download_file_(url, path, hasher, resume_from_partial, notify_handler).await {
   	Ok(_) => Ok(()),
   	Err(e) => {
   	if e.downcast_ref::<std::io::Error>().is_some() {
   	return Err(e);
   	}
   	let is_client_error = match e.downcast_ref::<DEK>() {
   	// Specifically treat the bad partial range error as not our
   	// fault in case it was something odd which happened.
   	Some(DEK::HttpStatus(416)) => false,
   	Some(DEK::HttpStatus(400..=499)) | Some(DEK::FileNotFound) => true,
   	_ => false,
   	};
   	Err(e).with_context(|| {
   	if is_client_error {
   	RustupError::DownloadNotExists {
   	url: url.clone(),
   	path: path.to_path_buf(),
   	}
   	} else {
   	RustupError::DownloadingFile {
   	url: url.clone(),
   	path: path.to_path_buf(),
   	}
   	}
   	})
   	}
   	}
   	}
5. rami3l

   modified the milestones: 1.28.0, On Deck on Jun 12, 2024
6. twuebi commented on Nov 23, 2024

   

   twuebi

   on Nov 23, 2024

   More actions

   Hi @rami3l, I also encountered the same issue with tests, searching for the cause, I came across this thread on the rust-lang forums. We started encountering the problem over at lakekeeper (lakekeeper/lakekeeper#548) after making our clients static with lazy-locks like you are doing here, I think that is the cause for the failures you've been observing.

   👀React with 👀1Reacted by rami3l
7. rami3l commented on Nov 25, 2024

   

   rami3l

   on Nov 25, 2024

   Last edited by rami3l

   MemberAuthor

   More actions

   Hi @rami3l, I also encountered the same issue with tests, searching for the cause, I came across this thread on the rust-lang forums. We started encountering the problem over at lakekeeper (lakekeeper/lakekeeper#548) after making our clients static with lazy-locks like you are doing here, I think that is the cause for the failures you've been observing.

   @twuebi Thanks a lot for the info! I think your observation is likely relevant as we currently use in-process testing for some commands even if it appears to be out-of-process (#3891).

   It could indeed be possible that something like 2261e26 is required for reqwest::Client as well.

   Anyway, I'll find some time to look into this.