[bugfix] Queue implicit accepts *before* other side effects (#4282)

This PR just fiddles with the order in which we process status create / boost / fave side effects and implicit acceptances. The goal is to try to make sure the Accept message gets sent to a remote instance *before* the interaction with an implicitly accepted status.

Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4282
Co-authored-by: tobi <tobi.smethurst@protonmail.com>
Co-committed-by: tobi <tobi.smethurst@protonmail.com>
This commit is contained in:
tobi 2025-06-20 15:38:23 +02:00 committed by tobi
commit 38ff88f006
3 changed files with 36 additions and 33 deletions

View file

@ -160,15 +160,6 @@ func (p *Processor) FaveCreate(
return nil, gtserror.NewErrorInternalError(err)
}
// Process new status fave side effects.
p.state.Workers.Client.Queue.Push(&messages.FromClientAPI{
APObjectType: ap.ActivityLike,
APActivityType: ap.ActivityCreate,
GTSModel: gtsFave,
Origin: requester,
Target: status.Account,
})
// If the fave target status replies to a status
// that we own, and has a pending interaction
// request, use the fave as an implicit accept.
@ -186,6 +177,16 @@ func (p *Processor) FaveCreate(
status.PendingApproval = util.Ptr(false)
}
// Queue remaining fave side effects
// (send out fave, update timeline, etc).
p.state.Workers.Client.Queue.Push(&messages.FromClientAPI{
APObjectType: ap.ActivityLike,
APActivityType: ap.ActivityCreate,
GTSModel: gtsFave,
Origin: requester,
Target: status.Account,
})
return p.c.GetAPIStatus(ctx, requester, status)
}