DEV: Run topic tracking state updates in defer queue. (PR #14454)

There is alot of potential for TopicTrackingState to become out of sync when running it in Sidekiq. If Sidekiq is delayed, the state being published may no longer make sense.

Follow-up to b1f32f2f5717c4f55b902485794e62b8cecd8522

GitHub

@jbrw Can you have a look at this? There is more potential for stuff to become out of sync if Sidekiq is ever delayed. I’ve switch this to run in a defer queue to address the original performance concerns.

There is some minor risk that stuff headed to defer will never run, will stuff “self correct”, if it is just a lost notification if you rudely stop Discourse I guess it is OK?

@SamSaffron Nope stuff will not self correct as we rely on the message bus messages to keep stuff in sync. The ideal state here is for us to publish the message within the same request but will need @jbrw to clarify why we moved stuff to Sidekiq in the first place.

I recall why this happened, in some cases you can trigger a huge amount of notification and in those cases stuff can time out while posting.

My thinking is … if stuff is getting out of hand we defer. Maybe if we are triggering tons of messages we ship stuff to sidekiq?

Also we can just workaround by by running the whole controller action in a hijack block.

Can you gather some typical timings here?

My guess here is that TopicTracking#publish_unread is fairly inefficient because we publish one message per TopicUser record in the DB.

Can I clarify how this is related to notifications?

sorry … I see… this is just about 2 new topics 1 unread topic and so on…

Recommend you time the block on a typical case, maybe only defer stuff is you know it is going to trigger a mess?