Improve slow user authorization if many orgs/repos

[MeurillonGuillaume]

This PR is a solution for #2502.

To resolve the issue a configuration option WOODPECKER_ASYNC_REPOSITORY_UPDATE has been added to allow administrators to decide how Woodpecker should deal with the repository update call that is part of the login flow. It can be either sync/async.
Sync is do-able for smaller organisations with few repositories, but larger organisations might opt for async to improve login speed at the cost of consistency. The repository list will be eventually consistent depending on the forge & store performance. The configuration flag was added to avoid altering default behavior for existing setups, unless changed by the administrator.

To improve UX for new users I made it mandatory for them to await the repository update, to avoid having new users log in to a blank homepage as this might be confusing. After this initial slow login they will also get async updates, and thus faster logins.

Closes #2502

[anbraten]

What do you think about letting the UI call the /refresh automatically. Basically:

1. click login
2. redirect to oauth with forge
3. redirect back to server (skip refresh, no need for a config option)
4. redirect back to the UI
5. the UI starts the refresh api call in the background
6. if done we update the internal repo store (this automatically reloads repo views etc)
7. and the UI redirects to the initially requested page

[MeurillonGuillaume]

Hi @anbraten

That is indeed an alternate approach to this issue, though I think it might get concerning at scale. Because

1. If everytime someone opens the /repos UI page triggers a full reload, that might end up triggering rate-limits on the forge, given enough users, organisations and/or repositories
2. I don't think repository access will in many cases change often enough to need to be reloaded (automatically) so often. In case there are actual changes that are not yet picked up, one can refresh manually with the UI change.

It could perhaps be an automated action in the login flow, which it is already with this change. Having it configurable is maybe unnecessary, but I didn't want to alter the behavior for organisations that have no problems currently.

[woodpecker-bot]

Surge PR preview deployment succeeded. View it at https://woodpecker-ci-woodpecker-pr-5665.surge.sh

[lafriks]

What do you think about letting the UI call the /refresh automatically

Isn't login sync used also for repo/org rights checks?

[myselfghost]

Is the root cause of the issue I raised (#5889 ) the same as this ?

[lafriks]

Is the root cause of the issue I raised (#5889 ) the same as this ?

No, all repos are needed here to sync permissions

[MeurillonGuillaume]

I wanted to follow up on this PR, as it’s been dormant for a while now.

The issue it addresses still exists: login time scales poorly with the number of orgs/repos due to synchronous forge synchronization during authentication, which has a noticeable UX impact for larger accounts.

If there’s any guidance on a preferred way to move forward, I’m happy to adapt or rework the PR accordingly.

And to anyone reading this: I wish you a happy new year, hopefully we can get this one fixed in 2026 🥳

[lafriks]

Personally I would like to see some warning shown in UI that user right sync while it is still in progress after login

[MeurillonGuillaume]

@lafriks That would indeed be better UX for the default (synchronous) login, but that doesn't resolve the original issue of large accounts/organisations taking a long time to log in. In my personal case it takes up to 2 minutes.

[lafriks]

I mean it would still be async, would login user instantly but would show permanent warning somewhere near top menu that user right synchronization is in progress and not all repositories could be accessible yet and would hide it when it's done