bug: Warpcast follow count vs. Hub follow count is different

[manan19]

What is the bug?

Warpcast returns 8089 follow count for fid 194 https://vasco.wtf/fid/194

But the hubs return 8030

8030 follows for fid 194 from nemes.farcaster.xyz:2283
8030 follows for fid 194 from hoyt.farcaster.xyz:2283

How can it be reproduced? (optional)
getLinksByTarget on grpc port

[manan19]

@sanjayprabhu Will this be addressed by the linked PR?

[sanjayprabhu]

No, it's some required apis to debug the issue. I haven't had time to investigate this yet. Probably this week.

[manan19]

We're also seeing an issue with an inconsistency for casts. This is quite a severe issue for us since it is breaking all feeds across multiple customers that contain this cast.

example -
This cast exists on Warpcast https://warpcast.com/slokh/0x5ba7ea43
but it was never broadcasted over farcaster mainnet.

https://hoyt.farcaster.xyz:2281/v1/castById?fid=3887&hash=0x5ba7ea43dd642868947f9e9fbfd125246c233e93
https://nemes.farcaster.xyz:2281/v1/castById?fid=3887&hash=0x5ba7ea43dd642868947f9e9fbfd125246c233e93

The cast was recasted 3 times & all the recast events were broadcasted over the network. Shouldn't the hubs have rejected the recast events if the cast didn't exist, was revoked, pruned or deleted?

[sanjayprabhu]

The above issue (which is unrelated to the count difference) should be fixed by #1610.

Also note that the hubs don't validate the target cast id. This is because they cannot rely on the messages arriving in order, so we have use less strict validations.

I'll leave this ticket open since I still want to get to the bottom of the count difference.

[manan19]

@sanjayprabhu Do we need to make any changes after the fix lands in a hubble upgrade to get that deleted signer again?

[sanjayprabhu]

Nope, hubble should fix itself on next sync (likely within 10-15 mins). I'm testing this now, and hoping to do a patch release later today.

[sds]

Closing as this should be fixed. Thanks for the report!