If I go to my network profile here:


I do not see this Super User question.

It could be possible that it's following an account merging, but is it possible to fix it by myself (like force a recalc on the network profile)?

Otherwise would it be possible to fix it?

Note that there is no evidence of restriction on my Super User profile.

  • There isn't any post before 2015 in your network profile either: stackexchange.com/users/activity/172198/… so there is definitely something missing, not just from the that Top tab.
    – rene
    Feb 9, 2019 at 8:48
  • @rene AFAIK, any tabs on Network profile is limited to 5 pages only (e.g. your profile). Feb 9, 2019 at 23:51
  • for the close vote, the reason says: "You should ask this question on the meta site where your concern originated" but tell me on which meta site I should ask for Network profile concerns? Network Profile is on the StackExchange site.
    – рüффп
    Feb 10, 2019 at 7:36
  • Yes it's most likely due to account merge, that didn't synch well with the network profile and all its related stats. Likely only a dev can force a proper synchronization. :( Feb 10, 2019 at 7:57
  • @рüффп please stop rolling back valid edits fixing your grammar. Feb 10, 2019 at 7:58
  • I'm a SU and MSE mod. I think it belongs here Feb 10, 2019 at 9:12
  • I did not rollback on purpose. I am not sure what action did that. I just wanted to see the close vote and because I clicked "close" instead the (1) it closes my question. I just reopen it. I am not sure that action did the rollback.
    – рüффп
    Feb 10, 2019 at 17:06
  • This does appear to be a bug with merges. Looking...
    – Shog9
    Feb 12, 2019 at 0:16

1 Answer 1


Leaving a note here, because it might be a bit before this is fixable & I don't want to forget about it.


There's a table in a database somewhere called NetworkPosts. This table holds metadata on every post on every site across the entire network. It's used for things that have to combine activity across all sites, such as the Hot Network Questions - and of course, your network profile.

This table gets populated and updated every time something makes relevant changes to a post, whether that's someone editing a title or the post getting closed or a change to the ID of the user who owns it. Every time one of those changes happen, on any site, an event is generated, enqueued in Redis, and eventually processed by the aggregator. Yes, that Aggregator.

When the aggregator processes an event, it runs a bit of code that performs the necessary updates. For example, if a title changes, it runs:

Update NetworkPosts Set Title = @Title Where SiteId = @SiteId And PostId = @PostId

Or if a user is deleted, it runs:

UPDATE NetworkPosts SET OwnerUserId = NULL WHERE SiteId = @SiteId AND OwnerUserId = @UserId

Or if a user is merged, it runs:

Update NetworkPosts Set OwnerUserId = @NewUserId Where SiteId = @SiteId And OwnerUserId = @UserId

The aggregator pulls events from the queue last-in first-out, stopping to process them when it has a healthy number of events - let's say, 20 of 'em. It sorts the events in that batch according to the order in which they were raised, and then runs the associated SQL to actually propagate the changes. Then it goes back to sucking in events from the queue.

The problem

Now, here's where things go wrong: merging a user generates a tidy pile of events.

  • The reputation of the users involved is changing - gotta propagate those changes
  • The merge itself is happening, which affects the aggregated users & posts & such. Gotta raise an event for that!
  • Once all their stuff gets moved over to the target user, the source user gets deleted - that's gotta get propagated too, or you'd still have a shell of the old user hanging around somewhere!

Plus, of course, the world doesn't stop every time a user gets merged; folks are still editing titles, and deleting posts, and creating new posts, and doing their own merges and so on. All that goes into the event queue as well.

...That LIFO queue. Which the aggregator is calmly sipping from the top of. Eventually, the aggregator manages to grab that "user deleted" event from the top of the queue without also grabbing the "user merged" event. Not realizing that there's a related merge to process, the aggregator happily processes the deletion... Which removes ownership from all the posts formerly owned by the source user (in the aggregated NetworkPosts table, not on the site where the posts actually live). When the merge event gets processed in the next batch, there are no posts remaining attributed to the source user - so nothing happens.

The Scope

Well, obviously this has been happening for years... Your merge happened back in 2015!

So, unsurprisingly, there are a few hundred thousand posts without their proper owners floating around the network. Fortunately, this only matters for network profiles - it doesn't actually affect the ownership of the post where it matters: on the site.

Still, it's hardly ideal.

The Solution

The proper fix here is... To process events in the order they're raised. Fortunately, Redis supports FIFO queues too, so this can happen - and in fact, our intrepid Architecture Team already had this on their TODO list. Not gonna happen overnight, but rest assured it will happen.

Once that's done, we can backfill the proper ownership data and your network profile will once again reflect your actual activity.

Big thanks for taking the time to report this!

  • 1
    Sounds like status-planned is fitting here then? :-) Feb 13, 2019 at 8:04
  • 1
    Thanks for your answer, I just noticed that in the top question recently even the bug is probably here since the merge in 2015 but did not pay attention to it before. Anyway it's good you found the cause and a potential solution. I am mot in a hurry for the fixing anyway, just let us know when you think the fix is done, I will check my data after that and give a feedback.
    – рüффп
    Feb 19, 2019 at 22:15

You must log in to answer this question.

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