Top Trending Topics doesn't seem to honour date picker/ranges

You can change the time range for " Community health" reports on the admin page which then updates all the graphs. However this doesn’t apply for the “Top Trending Topics”, which is a bit of disconnect. I did try a few API calls on the report, passing in date ranges, but these also didn’t seem to have an impact either.

I’m not sure how this is calculated, is it as an all time thing, or can we bucket it up into an adjustable range?

The reason is it’d be super cool to highlight trending topics, or to use them to provide feedback to others, eg “hey this is spiking, do we need to do X or Y to reduce the friction?” or “this topic is super active, let’s do a deep dive blog post”.

Note - I know /top/monthly exists. I don’t know if trending is supposed to be sufficiently distinctive.

If they are complimentary then that’s totally fine :slight_smile:

Oh, the date there only refers to the charts, not to anything else on the page.

Doing top referred over a year would be pretty expensive to say the least. I am open though to adding an extra link there to explore this data in different time ranges.

The first step would be fixing this (which is linked from: admin/reports)

https://meta.discourse.org/admin/reports/top_referred_topics?category_id=all&end_date=2018-07-18&start_date=2018-06-18

Going to this out to @joffreyjaffeux list to have a look when he has a chance.

Something like… ?

If so it’s coming very soon :wink:

3 Likes

we need to be absolutely sure we have guards here for data overload … if the query takes longer than say 20 seconds we should say:

“Sorry, query is taking too long, please pick a shorter interval”

1 Like

there’s a LIMIT, doesn’t sound enough ? If I make it reasonably low (10?) is it still too risky ?

Yeah that does nothing really, if we tell it to run an aggregate on 20 million rows … this can get too expensive fast. We need this thing to time out after 20 seconds and tip the user that … sorry we just can’t run that query for you.

I don’t know what the query looks like, but a typical problem with LIMIT is that it happens after the cost has happened. That is, it’s often more like a “post” filter than a “pre” filter.

Here it’s simply that even one record can take a lot of time on a very large database in specific cases.

3 Likes

Thanks for the feedback, looking forward to it in future release!

1 Like

This has been released and should be available to you at he url /admin/reports/top_traffic_sources at the next update.

5 Likes

This topic was automatically closed after 5 days. New replies are no longer allowed.