-get_file_by_sd_hash raises NoSuchSDHash if there is no file, which
otherwise doesn’t get trapped
-remove unnecessary try/except around _DownloadNameHelper.__init__
-don’t delete self.waiting_on[name]
-convert to inline callbacks
-return more errors than just timeouts
-delete on timeout
-have a more understandable return condition (first data blob having
downloaded)
-remove ManagedEncryptedFileDownloader._reupload
-clean up reflector functions in Daemon, move to reflector.reupload
-check ConnectionLost in reflector client
-close sd blob file handle when it wont be sent (otherwise read handle stays open)
-log reflector sd info
-give reflector client factory a lbry file
-add get_read_handle to file_utils
-don’t leave read handle hanging after creating lbry file
-get rid of threaded weirdness
-remove reflector functionality from Publisher
-fix updating with an existing stream
-reflect new stream in thread after broadcasting name claim
this fixes a bug where if github is down the app will fail to start.
-check for new version every 30 min instead of every 12 hours
-check connection problems every 30 seconds instead of every second
What was happening was the wallet claimed to be caught up before it
actually was and so the wallet’s local_height was still the value from
when lbry was last run, frequently more than 20 or 50 blocks
behind. _get_value_for_name uses the block at local_height as the
basis for the proof. If _get_value_for_name is called during that
time between when the wallet claims to be caught up and it actually
is, the “Block too deep error” happens. And since the discover page
of the UI does name resolution right away, the error basically happens
anytime somebody starts the app after not using it for a few hours.
This changes the startup behaviour of the wallet to
- use the `update` callback provided by lbryum
- check that local_height and network_height match before declaring
that the wallet has caught up
For reference, the error is raised here:
1b896ae75b/src/rpc/claimtrie.cpp (L688)
