Deprioritize project authorizations refresh on project bot user destroy

Eugie Limpinrequested to merge
el-deprio-authorizations-refresh-on-user-destroy into master

What does this MR do and why?

Destroying a member enqueues a high-urgency AuthorizedProjectsWorker per membership. The nightly bulk deletion of resource access token bots by ResourceAccessTokens::InactiveTokensDeletionCronWorker therefore saturates the urgent-authorized-projects shard: hundreds of refreshes exceed their 10s target, the concurrency limiter buffers the rest, and scheduling latency runs well past its SLO. This recurs almost every night — see the analysis linked under References.

Nothing waits on that refresh for a bot being deleted. A bot reaches projects only through a resource access token, GlobalPolicy prevents :log_in for it regardless of token state, and Users::DestroyService blocks it before destroying its memberships.

Scope: project bots only, and in practice only group access tokens

Gated on user.project_bot? — the resource access token user type, covering both project- and group-scoped tokens. Human deletions keep today's high-urgency behaviour.

In practice this only affects group access tokens. A project bot may hold exactly one membership (Member validates user_id uniqueness for project bots), so it is either a ProjectMember or a GroupMember, never both — and ProjectMember#refresh_member_authorized_projects never calls super, so the transient priority is set but ignored for project access token bots. Those continue through AuthorizedProjectUpdate::ProjectRecalculatePerUserWorker at urgency :high.

Why the delay is safe

InactiveTokensDeletionCronWorker selects only bots whose tokens have all been inactive for at least inactive_resource_access_tokens_delete_after_days, so there is no usable credential by construction.

References

Edited by Eugie Limpin

Merge request reports