bug(hubble): Fetch fname transfers when merge fails due to "username not registered"

[sanjayprabhu]

What is the bug?
Hubble only polls the fname server for new names every 5 seconds. This means, if a user registers an fid and an fid and submits UserDataAdd messages within 5 seconds, the username message will be rejected since the hub has not picked it up yet.

We should detect this failure, and check the transfer history for that fid and retry the message automatically. We should also put in some protections so this cannot be used to ddos the fname server (simple check like only x calls/min to the fname server should do, user registration is not high traffic)

How can it be reproduced? (optional)
Include steps, code samples, replits, screenshots and anything else that would be helpful to reproduce the problem.

Additional context (optional)
Add any other context about the problem here.

[manan19]

@sanjayprabhu can we bump on the priority on this? We're receiving a lot of missing fname reports.

[henryphaver]

Good finding @sanjayprabhu – We are also getting multiple reports on this from both developers and users. – Because of this issue no username is shown, but instead !123456 which renders the UX useless in almost all cases. Hope this gets prioritized.

[0xAegir]

+1 This is biting us as well.

[sanjayprabhu]

Are these fnames eventually fixed or are they still missing? Could you provide some examples? Trying to determine if this is related to the issue above or a separate issue. The above issue happens only for new registrations and should fix itself within a few minutes when our backend retries.

[andrewhong5297]

+10 this is making the query experience on Dune a bit buggy, a few users have brought this up

[henryphaver]

@sanjayprabhu Actually now 2/3 of the sample size fixed already by themselves. - Will check if the third one is pending refresh on test system. - If not then been stuck for longer. Will also get more samples. Will report back.