Expired authorization tokens in the database

[Gusted]

In the last week I've helped two people trying to diagnose a specific error:

could not load config from forge: configFetcher: fallback did not find config: user does not exist [uid: 0, name: ] user does not exist [uid: 0, name: ] user does not exist [uid: 0, name: ]

Examples: [1], [2].

I was able to diagnose this back to that the user for which the repository is tied to (this works a bit strange for repositories by organisations) had their authorization token expired and the refresh token was also expired. In both cases it seems the repositories did not see any activity for several months and because the expiry of authorization tokens is only checked on-demand it seems this simply caused the tokens to get expired. So its not a regression of any sorts.

This experience has raised a few questions for me and I would like to discuss how they could be solved.

Error

The specific error did not indicate at all why this happened, it was simply the error as that was the first API call that would use the expired credentials. It feels to me that Woodpecker has all the information to deduce that the authorization and refresh token has expired and should be able to show that this is the case (and for which user in the case of a organization). It also seems that when logging into Woodpecker CI the authorization is refreshed and I think this could be mentioned as a way of resolving this error.

Active checking of authorization

Would it make sense to do active checking of the expiry of authorization tokens? This would prevent the case that it can get expired in the first case when the refresh token is also expired. Given the two examples, not seeing activity for several months is something that's being done.

Authorization of organisation owned repositories

I'm not exactly sure if this can be fixed or documented but I was surprised to learn, as a user and administrator, that organisation owned repositories are tied to a individual user. This feels like something that needs to be shown in the settings and potentially allow it to be changed in the case that the user is no longer active in the organisation and might be removed or the user might even delete themselves (e.g. organisations of large OSS projects might face this).

[qwerty287]

Yes, that's a big limitation of our current system.

Related: #4558 #5590

And about your suggestion to change the user that's used to do the API calls (we call it the "repo user"):
#571

This user is necessary though. It is not possible in a different way, because you sometimes need a token even though there is no interaction (e.g. with a cron). But yes, being able to change it is missing.

[Gusted]

This user is necessary though. It is not possible in a different way, because you sometimes need a token even though there is no interaction (e.g. with a cron).

This I understood, however I never thought of it, before seeing the database model.

And about your suggestion to change the user that's used to do the API calls (we call it the "repo user"):
#571

Ah, that looks related indeed. I'll add some thoughts there.

[qwerty287]

Closing in favour of the linked issues