It looks like flair data has some issues, here are screenshots from my Wordpress.com blog and profile pages. As you can see I have ~1K rep on the Server Fault, but flair thinks that I have 137K more:

Wordpress.com Flair



  • 7
    Well, that's certainly... an odd bug.
    – Doorknob
    Jan 20, 2016 at 12:00
  • 6
    Looks like you got mixed up with SF top user, serverfault.com/users/13325 Jan 20, 2016 at 12:24
  • 6
    You must have been working really hard :D
    – nicael
    Jan 20, 2016 at 13:24
  • 4
    Well, congratulations, I guess. :) Jan 20, 2016 at 13:29
  • 13
    I blame Robin Hood. I knew it was just a matter of time before that scoundrel turned to rep.
    – Tim Post
    Jan 20, 2016 at 13:58
  • 2
    A fix is incoming, I'll post details here in a bit. Jan 20, 2016 at 17:07

2 Answers 2


So like most things in life, this was my fault. Historically we had 2 systems for getting data and never really finished moving to the latter. One of those artifacts came up with some Developer Timeline work that showed us doing an unnecessary HTTP request to the 2.0 API to get your user list for the Communities section of the profile. There's no need for that overhead, we've got database access.

We also didn't need to cache the number of strings returned with a !8.(3p54UxIbJyv5MuonC6aUPxvldcj7CbjQXT8 filter, since we have the sites readily available in local cache all we needed was an integer. So we could save time, an HTTP request, deserialization time, allocations, redis wire time, and memory all by switching over to a faster database query.

Paired with this was code cleanup: moving these methods from User since "getting other network users" didn't really belong there, to Account. That's where this line of code didn't get changed:

Hooks.UserReputationChanged(Id, user.Reputation, Current.Site.Id);

It should have been:

Hooks.UserReputationChanged(user.Id, user.Reputation, Current.Site.Id);

So...my bad. It should be fixed as cache expires since the place this happens is in the correction logic. This section of code was written to sync up what you see with what is returned. Since the network-wide aggregation can lag up to a second we need to replace the current-site data in the return set to match your top bar so it appears in sync. If a difference is detected, we also issue an aggregator request to fix it...just in case. That's the code that was getting hit here.

If anyone has more questions I can clarify a bit, I just thought some background on how this works may be helpful.


I found a pretty strange coincidence, after having seen @Sha's comment. The network-wide profile of ewwhite has this link:


And yours Server Fault profile has the same id:


This is weird, but could be the reason (and probably someone's else has been also affected).


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .