13

The 'badges' tab of the 'activity' section on network profiles is broken; it says

no activity found

enter image description here

0

1 Answer 1

7

I noticed this issue today, and investigated the query responsible for populating the Badges tab. We essentially do this (a quite simplified version of the query):

SELECT TOP (100) <stuff>
  FROM NetworkActivity AS NA
  LEFT JOIN NetworkPosts AS NP
  ON <same site and user>
  WHERE <NA.ActivityType is a badge>
  ORDER BY <newest>;

In January, a filter was added to make sure we only include posts that are in a specific state (published) - the reason was to exclude things like drafts and Staging Ground posts in various states (keep in mind, the logic that generates queries for the activity tab involves more than just badges). When the filter was added, the query became:

SELECT TOP (100) <stuff>
  FROM NetworkActivity AS NA
  LEFT JOIN NetworkPosts AS NP
  ON <same site and user>
  WHERE <NA.ActivityType is a badge>

    /* filter added here */
    AND NP.PostState = <published> 

  ORDER BY <newest>;

In SQL Server, if you add a WHERE clause to an outer joined table, you essentially turn that join into an inner join. Since most badges don't have an associated post, this means that for most users, the 100 most recent badges get filtered out, and the page is empty.

The fix is to move that new filter to the join criteria:

SELECT TOP (100) <stuff>
  FROM NetworkActivity AS NA
  LEFT JOIN NetworkPosts AS NP
  ON <same site and user>

    /* filter moved here */
    AND NP.PostState = <published> 

  WHERE <NA.ActivityType is a badge>
  ORDER BY <newest>;

I had a two-minute chat with the developer who introduced the change, and they fast-tracked a fix that should be working soon (it was deployed, then rolled back due to an unrelated change that broke network-wide search, and should be working again later today).

8
  • hehe. I think, almost sure, that whenever I saw staff saying "this is done now", it took way more than that until it was really done, some were not done until this very day. So, my pro tip: never say "now". Soon is indeed the correct word. :P Commented Apr 20, 2023 at 6:42
  • 2
    @ShadowTheSpringWizard Yes, I agree. In this case it was working, I swear. And we don't roll deployments back very often at all, this fix was just a victim of being shipped together with an unrelated regression.
    – Aaron Bertrand Staff
    Commented Apr 20, 2023 at 12:19
  • Yeah, edge case. Any ETA? Commented Apr 20, 2023 at 17:34
  • 1
    @ShadowTheSpringWizard Supposed to be today, I've already learned from this post alone that I'm not willing to speculate about anything more specific. :-)
    – Aaron Bertrand Staff
    Commented Apr 20, 2023 at 17:42
  • lol, good point. But if something went wrong, it's fair to say unknown, or 6-8 weeks which is the standard. (Or was, actually most bugs take either much longer if not critical, and critical bugs much less. :-)) Commented Apr 20, 2023 at 17:49
  • 1
    @ShadowTheSpringWizard It's closer to "stay tuned" than "unknown" - I just don't have that much visibility into actual deployment pipelines or, where I can see them, the ability to predict finish times for ones that are running. :-)
    – Aaron Bertrand Staff
    Commented Apr 20, 2023 at 17:52
  • 1
    @ShadowTheSpringWizard The fix appears to be in place again.
    – Aaron Bertrand Staff
    Commented Apr 20, 2023 at 18:37
  • Yay! happy dance Commented Apr 21, 2023 at 5:11

You must log in to answer this question.

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