Radish alpha
h
rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5
Radicle Heartwood Protocol & Stack
Radicle
Git
sync: Announcement prints error
Closed { reason: Solved } lorenz opened 1 year ago

Most users will have seen the following error printed by rad sync (and rad sync -a).

✗ Error: all seeds timed out

Most users will also know that this is not that big of a deal, because syncing still works. It is just very confusing for new users and therefore a really unfortunate hindrance to wider adoption.

I took a look and, as far as I understand, the crux is that nodes that already are in sync are not paid much attention. They are filtered out.

So, I would like to propose the following:

First, print information about nodes that are in sync already:

  • If the user has configured preferred seeds, their sync status should be printed always and explicitly. That is, for each preferred seed, I would like rad sync to print “✓ Preferred seed is in sync.” This will reassure the user on the sync status of the nodes they most likely care about.
  • For other seeds (i.e. ones that are not preferred), print the total number of seeds that are in sync.

Then, print that a message saying that syncing with additional nodes will be attempted. Once that is done, print a message per attempted sync, so that the user knows what’s going on. Again, print the preferred seeds that are now synced, and the number of additional nodes that are now synced.

Finally, to drive the point home, print “All preferred nodes are in sync.” or similar, if that is now the case, and print the total number of nodes that are in sync now.

I volunteer to implement something like this, probably with some variation as I go along, but would like to get feedback before I start.

fintohaps commented 1 year ago

Oh interesting, afair, we did a lot of work on this already and enusre that if you reach a certain replication factor and/or are synced with your preferred seeds then this error would not show up.

I like your proposal, it provides a lot of good information! I’d probably want to avoid the scenario we have with clone where there’s a bunch of errors and then suddenly the whole operation is a success. So, I’d like you to keep that in mind while you’re implementing it :)

z6MkgFq6...nBGz commented 7 months ago

Seems to be fixed with rad patch show 9436bda3902862b28f0ed7f52e97ff325566b008 et al. Closing now.