gitlab 19.4.1 & woodpecker v3 docker deployment

[d-shehu]

After seeing errors with complex pipelines I decided to upgrade my Gitlab to the latest stable release. I then revoked the app token and reauthorized Woodpecker. I was able to run a few builds but I started seeing issues with oath token expiring despite it being set to 2 hours in Gitlab.

One of the glitches actually failed the workflow which was triggered by a commit to Gitlab. Woodpecker log shows that auth token expired. I must be doing something wrong but I assume that builds should run without me having to log back in periodically every 2 hours.

Woodpecker server docker log

}\nGET https://gitlab/api/v4/projects/3: 401 {error: invalid_token}, {error_description: Token is expired. You can either do re-authorization or token refresh.}\nGET https://gitlab/api/v4/projects/3: 401 {error: invalid_token}, {error_description: Token is expired. You can either do re-authorization or token refresh.}","time":"2026-10-05T23:18:58Z","message":"error while fetching config '' in 'refs/heads/master' with user: 'automaton', and did not get any config"}
{"level":"error","error":"GET https://gitlab/api/v4/projects/3: 401 {error: invalid_token}, {error_description: Token is expired. You can either do re-authorization or token refresh.}","time":"2026-10-05T23:20:15Z","message":"failed to load branches"}
{"level":"error","error":"GET https://gitlab/api/v4/projects/3: 401 {error: invalid_token}, {error_description: Token is expired. You can either do re-authorization or token refresh.}","time":"2026-10-05T23:20:26Z","message":"failed to load branches"}
{"level":"error","error":"GET https://gitlab/api/v4/projects/3: 401 {error: invalid_token}, {error_description: Token is expired. You can either do re-authorization or token refresh.}","time":"2026-10-05T23:20:34Z","message":"failed to load branches"}
{"level":"error","error":"GET https://gitlab/api/v4/projects/3: 401 {error: invalid_token}, {error_description: Token is expired. You can either do re-authorization or token refresh.}","time":"2026-10-05T23:20:43Z","message":"failed to load branches"}

Obviously I can re-auth to see the dashboard. But the build should run.

I'll do some digging but the way it's working now was confusing so I thought I'd check first. Didn't want to log bogus bugs. Thanks.

[widechaos]

The expiry = -62135596800 in your SQLite output explains a refresh path that can fail silently. That is Go's zero time (0001-01-01), and oauth2.Token treats a zero expiry as having no expiry. With a nonempty access token, it can keep returning the old token without contacting GitLab. OAuth2 token handling.

In Woodpecker v3.18.0's GitLab refresh code, the stored access token, refresh token and time.Unix(user.Expiry, 0) are passed to TokenSource. For the value you posted, that reconstructs the zero time. The outer refresh check can run, while the inner token source returns the same access token successfully. That would explain both the later 401 and the absence of a refresh-failure log.

I checked this with golang.org/x/oauth2 v0.36.0 (the version pinned by v3.18.0) and a local mock token endpoint: your expiry value plus a dummy access token produced zero endpoint requests; passing only the refresh token produced one request and a new token with a nonzero expiry. I haven't reproduced your GitLab deployment.

So #7167, which you linked, is relevant: its proposed change forces the exchange by passing only the refresh token. It is still open, so I wouldn't assume it is included in your image. If you can test that change in a separate instance, check that a refresh request occurs and that the stored expiry becomes a real future timestamp.

There is also a separate question: why was the expiry zero after login? The login code stores the expiry returned by the OAuth library. I'd check whether GitLab's actual /oauth/token response includes a positive expires_in; the Rails database value alone doesn't establish what Woodpecker received. Share only expiry metadata, with access/refresh tokens and secrets removed. Extending the GitLab lifetime won't correct the zero-expiry handling in Woodpecker.

[6543]

thats a good cause analysis ....!

i did make #7284 ... it should push a test image to registry
if you want you can test if this solves it @d-shehu

[d-shehu]

Thanks for the deep dive. As I understand it the only way to test whether Gitlab's endpoint is giving out a valid expiry is to mock an app and log the auth flow. Is there an easier way?

I've enabled trace logging in Woodpecker so I'd expect the response to be logged but somehow couldn't find it. Perhaps I should look again?

As for the PR, I'll check it out once the next build is out.

[6543]

https://ci.woodpecker-ci.org/repos/3780/pipeline/38493/10

-> woodpecker-server:next-b9573e7f52

[widechaos]

You don't need a mock app to check GitLab. My mock only tested how Woodpecker's OAuth library handles the stored zero expiry; it didn't inspect your GitLab response. The relevant field is expires_in in the actual POST /oauth/token response (GitLab docs). I wouldn't rely on trace logging to include that response, and there's no need to share the access or refresh tokens.

For a simpler first test, use the test image 6543 linked above in a test instance, then check whether a refresh occurs and the stored expiry becomes a future timestamp. That would test the refresh fix. It would still leave the separate question of why the original login stored a zero expiry open.