Rewrite the ChainActivityHandler

[BentiGorlich]

• remove all redispatches of the ChainActivityMessage, just get all dependencies one by one in a recursive call
• adjust the 3 main sources for it: LikeHandler, DislikeHandler and AnnounceHandler (basically like, dislike and boost something that is not in our db)
• adjust the ApActivityRepository for better readability and remove the union select with 4 individual ones

For testing:

• you need 2 instances
• create a magazine and subscribe to it from both instances
• post something there
• at the other instance the post should be created automatically, purge it via the "moderate" panel
• from the instance where you didn't purge it: like/dislike/boost/comment on it
• The post should get recreated on the other instance

I tried it with 20 nested comments and purged the entire post. After liking the first comment everything got recreated

I really hope that this fixes one of our worst circular message offenders

[asdfzdfj]

might have to give this a try later

also for a second opinion, I also have my own take on reworking chain activity handler if anyone's interested, albeit it was made with a different rationale behind them, do let me know if you want PR of that patch

[BentiGorlich]

might have to give this a try later

also for a second opinion, I also have my own take on reworking chain activity handler if anyone's interested, albeit it was made with a different rationale behind them, do let me know if you want PR of that patch

I think I actually like my approach better, because it is more straight forward in what it does. But if you think differently I am happy to discuss how we want to change the handler (I mean it, I do not think that my code is just better 😅 )
The main difference in our code is that you build the chain first and then create db entries for them vs my approach to just do it directly after fetching the chain objects

Your code definitely has one giant problem though (if I am not mistaken): current ChainActivityMessages in delay queues can not be parsed as your new version of the ChainActivityMessage which is probably (maybe) the cause of the Invalid AMQP Data error which completely nukes the messengers (constant restarting without consuming the message). That's why I didn't want to change the message signature.

[asdfzdfj]

Your code definitely has one giant problem though (if I am not mistaken): current ChainActivityMessages in delay queues can not be parsed as your new version of the ChainActivityMessage which is probably (maybe) the cause of the Invalid AMQP Data error which completely nukes the messengers (constant restarting without consuming the message). That's why I didn't want to change the message signature.

you do raise an interesing point in terms of ensuring operation continuity, and yeah my patch does fall short on that part, but I think that could be work around: changed the name for the new ChainActivityMessage (BuildChainActivityMessage?), shim the existing ChainActivityMessage to redispatch itself into a new one, while also adjust the dispatching in like/announce handler to dispatch the new one, and then "deprecates" the old ChainActivityMessage after a release or two

though I have to say that I don't like the prospect of changing message signature nuking messenger systems very much if that's the case

I think I actually like my approach better, because it is more straight forward in what it does. But if you think differently I am happy to discuss how we want to change the handler (I mean it, I do not think that my code is just better 😅 )
The main difference in our code is that you build the chain first and then create db entries for them vs my approach to just do it directly after fetching the chain objects

as for this part I'm afraid that it'll devolve into mostly value differences, as I feel like "straight forward" for you and me is quite different here

what I've done in my patch is roughly a reimplementation of the same logic that I managed to untangle from the old handler, and try to express it in a more obvious way (as in, fewer and more visible actions/branches that should be more easy to follow through, rather than whatever nigh incomprehensible nested ifs and recursive bulls**t it used to be), and maybe do a bit of cleanup/unification/fixes along the way if applicable

actually, I'm quite sure the entire thing could be done with just plain loops, no recursion required, but for the time being I've allow it to recursive dispatch to allow interleaved message processing, as it could take some time for the chain processing to complete and I'm not sure of the performance impact when you have one (or possibly more) long chain message hogging the worker, maybe a bit of batching for building and consuming part could be done here

[BentiGorlich]

you do raise an interesing point in terms of ensuring operation continuity, and yeah my patch does fall short on that part, but I think that could be work around: changed the name for the new ChainActivityMessage (BuildChainActivityMessage?), shim the existing ChainActivityMessage to redispatch itself into a new one, while also adjust the dispatching in like/announce handler to dispatch the new one, and then "deprecates" the old ChainActivityMessage after a release or two

yeah that would work I think

though I have to say that I don't like the prospect of changing message signature nuking messenger systems very much if that's the case

Yeah we definitely need to test that. If that is correct we really have to keep it in mind (especially me, since I probably nuked it multiple times in the past with those changes)

as for this part I'm afraid that it'll devolve into mostly value differences, as I feel like "straight forward" for you and me is quite different here

Probably true. However I feel like the job of the ChainActivityHandler is super simple: fetch the missing parents of x activity and redispatch x afterwards.

My main goal was to get rid of the self dispatch, as I think it is just to easy to mess that up, be that in the initial implementation or in changes coming in the future.
I think my implementation achieves that. Yes it is doing a recursive method call, but imo that's way better and more failure resistant than doing it via a redispatch. I don't think that the maybe long runtime is a problem here, though that is quite difficult to say. For example you could have a nested comment with 20 parents coming before it, everyone with a unique image that needs to be fetched and none of them are from the same instance. That would probably take a while... But I prefer a long running message over a self dispatching one.

Again you are probably right a lot of it is preference, so maybe I should shut up and let melroy, e-five, debounced and others decide on what implementation they prefer 😅

[nobodyatroot]

So far so good, everything seems to be working fine.