From 9e24038ec27981b54eb80743b06eb92ea55cfaaa Mon Sep 17 00:00:00 2001 From: Pere Lev Date: Sat, 27 Apr 2024 20:13:01 +0300 Subject: [PATCH] Deliver activities to remote audience before local+collections This is an attempt to prevent remote activities from being received in the wrong order, for example Accept coming before the Add. Whenever that happens, the add-a-child-parent-link process cannot be completed. If this doesn't help, another option is to store, per actor, a list of activities that weren't used, and check them in relevant S2S handlers. This might have an implication on forwarding if it's time limited (I don't remember exactly). But worth trying. Example: - I receive an Accept on an activity I don't recognize - I store it in that list, for later - Later I receive an Add activity, which I successfully process - Now I check that Accept from earlier, seeing if its `object` happens to be the Add I just received - If yes, I now process this Accept A potential problem with this, is that I might accumulate a list of such activities, and end up hopelessly checking them in every S2S handler. And I wonde if this is really a healthy elegant approach to the ordering problem. Maybe some sort of activity numbering can help? --- src/Vervis/Actor2.hs | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/src/Vervis/Actor2.hs b/src/Vervis/Actor2.hs index 13a9d88..a5db385 100644 --- a/src/Vervis/Actor2.hs +++ b/src/Vervis/Actor2.hs @@ -1,6 +1,7 @@ {- This file is part of Vervis. - - - Written in 2019, 2020, 2022, 2023 by fr33domlover . + - Written in 2019, 2020, 2022, 2023, 2024 + - by fr33domlover . - - ♡ Copying is an act of love. Please copy, reuse and share. - @@ -189,6 +190,10 @@ sendActivity -- ^ Activity to send to remote actors -> Act () sendActivity senderByKey senderActorID localRecips remoteRecips fwdHosts itemID action = do + envelope <- do + senderByHash <- hashLocalActor senderByKey + prepareSendH senderActorID senderByHash itemID action + sendByHttp envelope remoteRecips moreRemoteRecips <- do let justSender = Just senderByKey author = (senderByKey, senderActorID, itemID) @@ -207,29 +212,24 @@ sendActivity senderByKey senderActorID localRecips remoteRecips fwdHosts itemID Right o -> return o let body = ActivityBody bodyBL bodyO act sendToLocalActors (Left author) body True justSender justSender localRecips - envelope <- do - senderByHash <- hashLocalActor senderByKey - prepareSendH senderActorID senderByHash itemID action - let (yesFwd, noFwd) = - let remoteRecipsList = - concatMap - (\ ((_, h), rrs) -> NE.toList $ NE.map (decideFwd h . remoteRecipientId) rrs) - moreRemoteRecips - moreList = - concatMap - (\ (h, lus) -> NE.toList $ NE.map (decideFwd h) lus) - remoteRecips - allRemotes = remoteRecipsList ++ moreList - in partitionEithers allRemotes - dt <- asksEnv stageDeliveryTheater - liftIO $ do - sendHttp dt (MethodDeliverLocal envelope True) yesFwd - sendHttp dt (MethodDeliverLocal envelope False) noFwd + sendByHttp envelope $ + map (\ ((_, h), rrs) -> (h, NE.map remoteRecipientId rrs)) + moreRemoteRecips where decideFwd h = if h `elem` fwdHosts then Left . ObjURI h else Right . ObjURI h + sendByHttp envelope recips = do + let recipsDecided = + concatMap + (\ (h, lus) -> NE.toList $ NE.map (decideFwd h) lus) + recips + (yesFwd, noFwd) = partitionEithers recipsDecided + dt <- asksEnv stageDeliveryTheater + liftIO $ do + sendHttp dt (MethodDeliverLocal envelope True) yesFwd + sendHttp dt (MethodDeliverLocal envelope False) noFwd prepareForwardIK :: (Route App, ActorKey)