hyper via reqwest panics with "dispatch dropped without returning error"

Our app makes use of reqwest on a separate process to send HTTP requests. The app can be restarted a number of ways, such as updates for example. If an HTTP request is currently in transmission at the time our app is restarting, we begin to see the following panic. I saw source of the panic comes from hyper, as well as a comment implying this is a bug that hadn't been fixed. It'd be great if this can be resolved.

thread 'tokio-runtime-worker' panicked at 'dispatch dropped without returning error', <::std::macros::panic macros>:2:4
stack backtrace:
   0: 0x78cf01ed - bz_internal_error
   1: 0x790fd940 - rust_eh_personality
   2: 0x790fd41c - rust_eh_personality
   3: 0x790fc7c4 - rust_eh_personality
   4: 0x78a47808 - call
   5: 0x790fc2d6 - rust_eh_personality
   6: 0x7903a31d - rust_eh_personality
   7: 0x7904d55b - rust_eh_personality
   8: 0x7904911f - rust_eh_personality
   9: 0x7879b712 - <unknown>
  10: 0x787932eb - <unknown>
  11: 0x78b52dff - call
  12: 0x788ddeeb - <unknown>
  13: 0x788742b7 - <unknown>
  14: 0x7912c9aa - rust_eh_personality
  15: 0x7912a346 - rust_eh_personality
  16: 0x79128d7c - rust_eh_personality
  17: 0x7912847a - rust_eh_personality
  18: 0x79127ee1 - rust_eh_personality
  19: 0x79115f4b - rust_eh_personality
  20: 0x791181e7 - rust_eh_personality
  21: 0x769b6359 - BaseThreadInitThunk
  22: 0x773b7b74 - RtlGetAppContainerNamedObjectPath
  23: 0x773b7b44 - RtlGetAppContainerNamedObjectPath

Thanks!

Start by tracing the hyper dispatch path associated with the reported "dispatch dropped without returning error" panic, using the provided restart-during-transmission scenario as the reproduction case. Done means an interrupted request no longer panics and instead completes with an appropriate error; the issue names no source file or test to run.