ord env less aggressive exit

[raphjaph]

We were very aggressive with killing the process. Not allowing Bitcoinn Core time to process the kill command, which lead it to bork it's database. This now waits 5 seconds, giving it enough time to exit.

[casey]

Five seconds feels like a long time to wait. Can we get away with less?

[raphjaph]

It's not really critical that this shuts down fast. It's more important that Bitcoin Core doesn't get borked. We could probably test and reduce by 2-3 seconds but I'd rather be on the safe side.

The borked database is also a very insidious error because Bitcoin Core just starts up from block 0 and doesn't tell you something went wrong previously. The ord index there-while thinks it's at block 200 but also doesn't complain.

[cryptoni9n]

Might fix #4164

We were very aggressive with killing the process. Not allowing Bitcoinn Core time to process the kill command, which lead it to bork it's database. This now waits 5 seconds, giving it enough time to exit.

I made the timeout changes manually and created a new build from Master to test with. Unfortunately, I see no little difference in the behavior.

I think that a key aspect to this issue is that once env is built and started, it can not be inscribed to. When attempted, it throws the following error:

F:\0.22.1_env_test\release>ord --data-dir env wallet inscribe --fee-rate 5 --file "F:\Bitcoin\art projects\ANDRE.webp"
error: JSON-RPC error: RPC error response: RpcError { code: -4, message: "Wallet is currently rescanning. Abort existing rescan or wait.", data: None }
   0: std::backtrace_rs::backtrace::dbghelp64::trace
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14\library/std\src\..\..\backtrace\src\backtrace\dbghelp64.rs:91
   1: std::backtrace_rs::backtrace::trace_unsynchronized
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14\library/std\src\..\..\backtrace\src\backtrace\mod.rs:66
   2: std::backtrace::Backtrace::create
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14\library/std\src\backtrace.rs:331
   3: std::backtrace::Backtrace::capture
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14\library/std\src\backtrace.rs:296
   4: anyhow::error::<impl core::convert::From<E> for anyhow::Error>::from
   5: <T as ord::subcommand::Output>::print
   6: <T as ord::subcommand::Output>::print
   7: ord::subcommand::wallet::inscribe::Inscribe::run
   8: ord::subcommand::wallet::WalletCommand::parse_metadata
   9: ord::arguments::Arguments::run
  10: ord::main
  11: __ImageBase
  12: __ImageBase
  13: std::rt::lang_start_internal::closure$2
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14\library/std\src\rt.rs:143
  14: std::panicking::try::do_call
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14\library/std\src\panicking.rs:554
  15: std::panicking::try
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14\library/std\src\panicking.rs:518
  16: std::panic::catch_unwind
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14\library/std\src\panic.rs:345
  17: std::rt::lang_start_internal
             at /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14\library/std\src\rt.rs:143
  18: main
  19: invoke_main
             at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  20: __scrt_common_main_seh
             at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
  21: BaseThreadInitThunk
  22: RtlUserThreadStart

shutting down then produces the two kill errors:

F:\0.22.1_env_test\release\ord.exe --datadir env wallet balance
Shutting down gracefully. Press <CTRL-C> again to shutdown immediately.
Shutting down gracefully. Press <CTRL-C> again to shutdown immediately.
kill: 29276: No such process
kill: 30912: No such process

The only difference I see is that after restarting and checking the balance again, it seems to be maintained:

F:\0.22.1_env_test\release>ord --data-dir env wallet balance
{
  "cardinal": 500000000000,
  "ordinal": 0,
  "runes": {},
  "runic": 0,
  "total": 500000000000
}

but trying to inscribe again throws the same error.

[raphjaph]

Ok thanks for the report @cryptoni9n! Seems to only have fixed one issue. For the main issue I'll continue investigating