16:49:30 When you change the restore height in "Settings->Info->Wallet restore height" a prompt appears "Set a new restore height...", if you click the "Ok" button another prompt appears that asks "Are you sure you want to rebuild the wallet cache". Is it intended that if you cancel the second prompt the restore height still gets changed? That leaves you with a different height in the sett 16:49:30 ings than what the wallet actually used to scan. I can't judge if this could lead to some kind of undefined behavior or if there is a reason to do it like that. 17:33:59 If you cancel the second prompt abd the wallet does not start rescanning, then it should probably revert the value to the old one 17:34:41 Or better, it shouldnt change the value until the second prompt is confirmed 17:35:11 if true sounds like a bug - are you sure? (lol jk) 17:35:54 or the number is in settings but not applied, possible 17:38:12 will repro now 17:39:42 and my testnet node is offline brb 17:43:50 that's what I assumed, made that change in an upcoming PR, but thought maybe I'm missing something 17:46:13 sneedlewoods yes, it only effects the number in settings and does not actually do anything to the cache. the new (fake) resotre height persists after restarting gui 17:47:43 you also agree that's probably not intended? 17:50:19 correct , will be an assumption made in the javascript menus at a guess 17:50:43 the original value probably not saved , just guessing 17:51:21 but wait sneedlewoods, monero-wallet-cli says the restore height is 0 17:53:16 so the wallet file has been modified by the gui after cancelling the change, but it didnt take effect? :-S 17:54:42 cancel change in gui -> open wallet in cli -> open wallet in gui (see the cache has to be rebuilt msg) -> ?? 17:54:45 for me monero-wallet-cli gives the same restore height as GUI, after changing in GUI and then canceling the rescan 17:55:32 ah ok. sorry . ignore what i said. wrong monero version 18:03:33 I think the cache file is probably deleted after confirming (?) 18:11:39 it will move `` to `.old_cache` if you confirm, this can also lead to undefined behavior if you don't save the new `` first 18:11:40 E.g. changing the password after confirming to rescan gives a `boost::filesystem::canonical` error 18:11:42 Trying to solve this too