Update check takes a *very* long time to fail

[darconeous]

I noticed espflash recently started taking waaaaay longer to run on my system. A quick check of spindump indicates that it is the update check:

  Thread 0x1b6992    DispatchQueue 8593903736    Thread name "main"    1000 samples (1-1000)    priority 31 (base 31)    cpu time <0.001s (418.5K cycles, 303.8K instructions, 1.38c/i)
  1000  start + 6076 (dyld + 27544) [0x191f16b98]
    1000  main + 52 (espflash + 59996) [0x1026d2a5c]
      1000  std::rt::lang_start_internal::hf1bc3d9041088441 + 1092 (espflash + 4563708) [0x102b1e2fc]
        1000  std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::hcecb4b2108061204 + 24 (espflash + 110124) [0x1026dee2c]
          1000  std::sys::backtrace::__rust_begin_short_backtrace::hf37fd002135a5bfb + 12 (espflash + 110252) [0x1026deeac]
            1000  espflash::main::hc5cf7b388402f9f5 + 2656 (espflash + 30488) [0x1026cb718]
              1000  espflash::update::check_for_update::hdf20ab91f6a795be + 68 (espflash + 745492) [0x10277a014]
                1000  _$LT$update_informer..UpdateInformer$LT$R$C$N$C$V$C$H$GT$$u20$as$u20$update_informer..Check$GT$::check_version::h62dafe67df2fe815 + 188 (espflash + 398296) [0x1027253d8]
                  1000  _$LT$update_informer..registry..crates..Crates$u20$as$u20$update_informer..registry..Registry$GT$::get_latest_version::hd180724bf40f7a9e + 188 (espflash + 264600) [0x102704998]
                    1000  _$LT$update_informer..http_client..ureq..UreqHttpClient$u20$as$u20$update_informer..http_client..HttpClient$GT$::get::h1c4a02b0a057ea9e + 476 (espflash + 340108) [0x10271708c]
                      1000  ureq::request::Request::call::h5a2c677f461a223c + 28 (espflash + 1234500) [0x1027f1644]
                        1000  ureq::request::Request::do_call::h044a2578f16a739e + 1064 (espflash + 1235968) [0x1027f1c00]
                          1000  ureq::request::Request::do_call::_$u7b$$u7b$closure$u7d$$u7d$::ha2c6985574863407 + 252 (espflash + 1238148) [0x1027f2484]
                            1000  ureq::unit::connect::h2314c65efd77b7a9 + 108 (espflash + 1182024) [0x1027e4948]
                              1000  ureq::unit::connect_inner::ha0f19da73d8817f6 + 96 (espflash + 1185852) [0x1027e583c]
                                1000  ureq::unit::connect_socket::h03ff9901a7fa46f8 + 1520 (espflash + 1190152) [0x1027e6908]
                                  1000  ureq::stream::connect_https::hcedd3b091c657d89 + 96 (espflash + 1221224) [0x1027ee268]
                                    1000  ureq::stream::connect_host::h8fd0f7510c0ded35 + 1928 (espflash + 1224544) [0x1027eef60]
                                      1000  poll + 8 (libsystem_kernel.dylib + 38040) [0x19227d498]

There is the -S command line option, which helps, but it seems like espflash is invoked in other places during the build process which makes building and flashing take FOREVER. I can't just add -S wherever it is invoked because I don't control every place where it is invoked.

The timeout on checking for software update availability should really have an upper bound of closer to 4-5 seconds rather than 30+ seconds. Ideally, the software update check would happen on another thread and just report at the end. Maybe save when the last check was performed so that it is only checked once or twice a day, even if it fails. There has got to be a way to make this less painful when it can't perform a software update.

Just a suggestion.

[MabezDev]

A PR to reduce the timeout would be welcome :).

[jessebraham]

Not entirely sure what the issue is here, the timeout should be 5 seconds by default. I've created a branch which explicitly sets the timeout, and also reverts to the original interval which should prevent the check from running on each invocation of the tool. You can try this out to see if it improves things, and if it resolves the problem then I'm happy to merge these changes.

We additionally have added an environment variable ESPFLASH_SKIP_UPDATE_CHECK to disable the update checks, FYI.