Extends this PR with a further bump: meet-frontend + meet-backend + celery v1.24.0 → v1.25.2 (matched set, monorepo tag — they move together).
Image tags
service
image
was
now
app
lasuite/meet-frontend
v1.24.0
v1.25.2
backend
lasuite/meet-backend
v1.24.0
v1.25.2
celery
lasuite/meet-backend
v1.24.0
v1.25.2
(livekit v1.13.5, redis 8.10.0, nginx 1.31.3, pgautoupgrade 18-debian — all up-to-date, unchanged; carried from the prior v1.24.0 bump already in this PR.)
None — no breaking changes to recipe compose/config. Backend runs Django DB migrations on boot (automatic, watch backend logs on upgrade). livekit-server v1.13.5 remains compatible (v1.25.0 upgraded the frontend livekit-client JS library, not the server).
Release (operator, after merge)
abra recipe release lasuite-meet -y
Tested green on the cc-ci recipe CI server (full suite, cold, against this PR head). NOT merged — for operator review.
autonomic-bot
changed title from chore: upgrade livekit to v1.13.2 to chore: upgrade app/backend/celery to v1.23.0, livekit to v1.13.32026-07-13 23:10:10 +00:00
The WIP converges end-to-end on a direct --chaos deploy: all 7 services 1/1, Django migrations core.0007→0020 applied OK, gunicorn up, celery ready, livekit reports "version": "1.13.3", frontend serves.
Every tier except functional passes, including test_upgrade_preserves_data and test_oidc_password_grant_against_dep_keycloak (OIDC password grant still yields a valid JWT).
The single failing test is stale for meet ≥ v1.22.0
Assertion: room create returned HTTP 401 (expected 201); body={'detail': 'Authentication credentials were not provided.'}
The test obtains an OIDC user access token via password grant and uses it directly as a Bearer token for POST /api/v1.0/rooms/ (Authorization: Bearer <oidc-access-token>).
meet v1.22.0 intentionally changed this: the release notes list 🛂(backend) reject user access tokens on the API. The OIDC user access token is no longer accepted as an API bearer — hence the 401 "Authentication credentials were not provided." This is an intentional security hardening in upstream, not a recipe config gap (there is no env var that re-enables user access tokens on the API; doing so would defeat the fix).
The OIDC test that passed (test_oidc_password_grant_against_dep_keycloak) only verifies the grant yields a JWT — it does not use the token as an API bearer, which is why it still passes while this test fails. This confirms the failure is specifically the API-auth pattern, not OIDC provisioning.
Why this is a stale test (not an upgrade regression)
The test asserts the pre-v1.22.0 auth behavior (OIDC access token → Meet API bearer). meet v1.22.0 deliberately rejects that pattern. The test needs to adopt whatever API-auth mechanism v1.22.0+ expects (e.g. a Meet-issued API token, session-cookie auth, or a different token exchange) — that is a test update, gated by --with-tests.
Recommended next step
Re-run /recipe-upgrade lasuite-meet --with-tests to also open + verify a cc-ci test-update PR that updates test_meeting_flow.py to the v1.22.0+ API-auth mechanism. This recipe PR is otherwise ready (image bumps + config unchanged; recommended operator release: abra recipe release lasuite-meet -y).
Nothing was merged. The recipe PR awaits operator review; the test update is opt-in via --with-tests.
<!-- cc-ci:upgrade-diagnosis -->
## Upgrade diagnosis — `!testme` RED on a stale test (DEFAULT mode: comment, no test edit)
**Run #1122** (head `5124fd4e`): level 3/5 — `install` ✅, `upgrade` ✅, `backup_restore` ✅, `lint` ✅, **`functional` ❌**.
### The upgrade itself looks correct
- The WIP converges end-to-end on a direct `--chaos` deploy: all 7 services 1/1, Django migrations `core.0007`→`0020` applied OK, gunicorn up, celery ready, livekit reports `"version": "1.13.3"`, frontend serves.
- Every tier except `functional` passes, including `test_upgrade_preserves_data` and `test_oidc_password_grant_against_dep_keycloak` (OIDC password grant still yields a valid JWT).
### The single failing test is stale for meet ≥ v1.22.0
**Failing test:** `tests/lasuite-meet/custom/test_meeting_flow.py::test_create_room_get_livekit_token_and_read_back`
- Assertion: `room create returned HTTP 401 (expected 201); body={'detail': 'Authentication credentials were not provided.'}`
- The test obtains an OIDC **user access token** via password grant and uses it directly as a Bearer token for `POST /api/v1.0/rooms/` (`Authorization: Bearer <oidc-access-token>`).
- **meet v1.22.0 intentionally changed this:** the release notes list `🛂(backend) reject user access tokens on the API`. The OIDC user access token is no longer accepted as an API bearer — hence the 401 "Authentication credentials were not provided." This is an intentional security hardening in upstream, **not** a recipe config gap (there is no env var that re-enables user access tokens on the API; doing so would defeat the fix).
- The OIDC test that passed (`test_oidc_password_grant_against_dep_keycloak`) only verifies the grant yields a JWT — it does **not** use the token as an API bearer, which is why it still passes while this test fails. This confirms the failure is specifically the API-auth pattern, not OIDC provisioning.
### Why this is a stale test (not an upgrade regression)
The test asserts the **pre-v1.22.0** auth behavior (OIDC access token → Meet API bearer). meet v1.22.0 deliberately rejects that pattern. The test needs to adopt whatever API-auth mechanism v1.22.0+ expects (e.g. a Meet-issued API token, session-cookie auth, or a different token exchange) — that is a **test update**, gated by `--with-tests`.
### Recommended next step
Re-run `/recipe-upgrade lasuite-meet --with-tests` to also open + verify a cc-ci test-update PR that updates `test_meeting_flow.py` to the v1.22.0+ API-auth mechanism. This recipe PR is otherwise ready (image bumps + config unchanged; recommended operator release: `abra recipe release lasuite-meet -y`).
Nothing was merged. The recipe PR awaits operator review; the test update is opt-in via `--with-tests`.
autonomic-bot
changed title from chore: upgrade app/backend/celery to v1.23.0, livekit to v1.13.3 to chore: upgrade app/backend/celery to v1.24.0, livekit to v1.13.4, nginx to 1.31.32026-07-24 04:43:43 +00:00
Upgrade diagnosis — !testme RED on a stale test (DEFAULT mode: comment, no test edit)
Run #1137 (head 8aff5222, lasuite/meet v1.24.0 + livekit v1.13.4 + nginx 1.31.3): level 3/5 — install✅, upgrade✅, backup_restore✅, lint✅, functional❌ — single test failure, same root cause as the prior diagnosis at v1.23.0 (the API token hardening has not been reverted in v1.24.0).
The upgrade itself looks correct
Direct --chaos deploy on the cc-ci swarm converges cleanly with the new tags: all 7 services 1/1, Django migrations core.0009→0020 + easy_thumbnails/sessions/sites applied OK via AUTO_MIGRATIONS=true, gunicorn up (workers booted), celery ping healthy, livekit reports "version": "1.13.4", nginx 1.31.3 healthy, frontend serves.
Every CI tier except functional passes, including test_upgrade_preserves_data, test_oidc_password_grant_against_dep_keycloak, and test_lasuite_meet_returns_200.
The single failing test is stale for meet ≥ v1.22.0
Assertion: room create returned HTTP 401 (expected 201); body={'detail': 'Authentication credentials were not provided.'}
The test obtains an OIDC user access token via password grant and uses it directly as a Bearer token for POST /api/v1.0/rooms/ (Authorization: Bearer <oidc-access-token>).
meet v1.22.0 intentionally changed this (release notes: 🛂(backend) reject user access tokens on the API). The OIDC user access token is no longer accepted as an API bearer — hence the 401 "Authentication credentials were not provided." This is an intentional upstream security hardening, not a recipe config gap (the OIDC password-grant path and the health/landing endpoints still pass). The hardening is still in effect in v1.23.0 and v1.24.0.
Operator action
The recipe upgrade is correct and ready to merge — nothing in it needs changing.
To make !testme go green here, the cc-ci test needs updating (the room-creation functional test must mint an API-acceptable token / use the backend's own auth path rather than a raw OIDC user access token). In DEFAULT mode this skill does NOT modify tests.
Re-run /recipe-upgrade lasuite-meet --with-tests to also open + verify a cc-ci test-update PR that fixes this assertion.
This comment is for the v1.24.0 run; the prior comment (run #1122, head 5124fd4e) made the same diagnosis at v1.23.0. NOT merged — for operator review.
<!-- cc-ci:upgrade-diagnosis -->
## Upgrade diagnosis — `!testme` RED on a stale test (DEFAULT mode: comment, no test edit)
**Run #1137** (head `8aff5222`, lasuite/meet **v1.24.0** + livekit **v1.13.4** + nginx **1.31.3**): level 3/5 — `install` ✅, `upgrade` ✅, `backup_restore` ✅, `lint` ✅, **`functional` ❌** — single test failure, same root cause as the prior diagnosis at v1.23.0 (the API token hardening has not been reverted in v1.24.0).
### The upgrade itself looks correct
- Direct `--chaos` deploy on the cc-ci swarm converges cleanly with the new tags: all 7 services 1/1, Django migrations `core.0009`→`0020` + `easy_thumbnails`/`sessions`/`sites` applied OK via `AUTO_MIGRATIONS=true`, gunicorn up (workers booted), celery ping healthy, livekit reports `"version": "1.13.4"`, nginx 1.31.3 healthy, frontend serves.
- Every CI tier except `functional` passes, including `test_upgrade_preserves_data`, `test_oidc_password_grant_against_dep_keycloak`, and `test_lasuite_meet_returns_200`.
### The single failing test is stale for meet ≥ v1.22.0
**Failing test:** `tests/lasuite-meet/custom/test_meeting_flow.py::test_create_room_get_livekit_token_and_read_back`
- Assertion: `room create returned HTTP 401 (expected 201); body={'detail': 'Authentication credentials were not provided.'}`
- The test obtains an OIDC **user access token** via password grant and uses it directly as a Bearer token for `POST /api/v1.0/rooms/` (`Authorization: Bearer <oidc-access-token>`).
- **meet v1.22.0 intentionally changed this** (release notes: `🛂(backend) reject user access tokens on the API`). The OIDC user access token is no longer accepted as an API bearer — hence the 401 "Authentication credentials were not provided." This is an intentional upstream security hardening, **not** a recipe config gap (the OIDC password-grant path and the health/landing endpoints still pass). The hardening is still in effect in v1.23.0 and v1.24.0.
### Operator action
- The recipe upgrade is correct and ready to merge — nothing in it needs changing.
- To make `!testme` go green here, the **cc-ci test** needs updating (the room-creation functional test must mint an API-acceptable token / use the backend's own auth path rather than a raw OIDC user access token). In DEFAULT mode this skill does NOT modify tests.
- Re-run `/recipe-upgrade lasuite-meet --with-tests` to also open + verify a cc-ci test-update PR that fixes this assertion.
This comment is for the v1.24.0 run; the prior comment (run #1122, head `5124fd4e`) made the same diagnosis at v1.23.0. NOT merged — for operator review.
The stale cc-ci test blocking this PR is now fixed and merged: cc-ci PR #13
(recipe-maintainers/cc-ci#13) replaces the rejected raw-Bearer
auth with the real OIDC authorization-code session login (meet v1.22.0+ API auth hardening).
Verified GREEN: cold full-suite ×1 against THIS PR's head (8aff5222) with the updated tests —
install/upgrade/backup/restore/custom all pass. A fresh !testme will now run with the merged
tests. Merging this PR ⇒ green.
The stale cc-ci test blocking this PR is now **fixed and merged**: cc-ci PR #13
(https://git.autonomic.zone/recipe-maintainers/cc-ci/pulls/13) replaces the rejected raw-Bearer
auth with the real OIDC authorization-code session login (meet v1.22.0+ API auth hardening).
Verified GREEN: cold full-suite ×1 against THIS PR's head (8aff5222) with the updated tests —
install/upgrade/backup/restore/custom all pass. A fresh `!testme` will now run with the merged
tests. Merging this PR ⇒ green.
autonomic-bot
changed title from chore: upgrade app/backend/celery to v1.24.0, livekit to v1.13.4, nginx to 1.31.3 to chore: upgrade meet to v1.24.0, livekit to v1.13.5, redis to 8.10.0, nginx to 1.31.32026-08-04 01:29:59 +00:00
autonomic-bot
changed title from chore: upgrade meet to v1.24.0, livekit to v1.13.5, redis to 8.10.0, nginx to 1.31.3 to chore: pin redis to 8.8.1 (patch over 8.10.0 minor for sidecar cache)2026-08-04 01:55:58 +00:00
autonomic-bot
changed title from chore: pin redis to 8.8.1 (patch over 8.10.0 minor for sidecar cache) to chore: upgrade meet to v1.24.0 + livekit v1.13.5 + redis 8.8.1 + nginx 1.31.32026-08-04 01:56:23 +00:00
Drone build #1188 — full cold suite GREEN (recipe-ci stage: success). Triggered via direct Drone API (bridge stale-token workaround; scoped GITEA_TOKEN minted for the runner, deleted after).
Final pins on this PR head: meet v1.24.0, livekit v1.13.5, redis 8.8.1, nginx 1.31.3. The stale meeting-flow test (cc-ci PR #13, merged) is now satisfied.
<!-- cc-ci:testme -->
🌻 **cc-ci** — `lasuite-meet` @ `8e99426b` ✅ **passed**
[](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1188)
[](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1188)
**Drone build #1188** — full cold suite GREEN (recipe-ci stage: success). Triggered via direct Drone API (bridge stale-token workaround; scoped GITEA_TOKEN minted for the runner, deleted after).
Final pins on this PR head: meet v1.24.0, livekit v1.13.5, redis 8.8.1, nginx 1.31.3. The stale meeting-flow test (cc-ci PR #13, merged) is now satisfied.
[full logs](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1188) · [dashboard](https://ci.commoninternet.net/)
Triggered via the Drone-direct workaround (the ccci-bridge is silently dropping !testme triggers due to a stale gitea-bot swarm secret returning HTTP 401 — known infra issue, not fixed here).
A scope-limited gitea token (id 50, ccci-upgrade-lasuite-meet-20260803) was minted for this run and passed as GITEA_TOKEN to the Drone build so the runner's _gitea_token() could clone the recipe repo despite the stale bridge secret. The token will be deleted after this run.
Recipe upgrade verified GREEN. NOT merged — for operator review.
**cc-ci !testme verdict: VERDICT=GREEN** 🟢
Triggered via the **Drone-direct workaround** (the ccci-bridge is silently dropping `!testme` triggers due to a stale gitea-bot swarm secret returning HTTP 401 — known infra issue, not fixed here).
- Drone build: https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1190
- Build #: 1190 (status: success)
- Recipe: lasuite-meet @ 8e99426b (PR #8 head)
- Tiers: install ✓, upgrade ✓, backup ✓, restore ✓, custom ✓ (test_health_check, test_meeting_flow, test_oidc_with_keycloak)
A scope-limited gitea token (id 50, `ccci-upgrade-lasuite-meet-20260803`) was minted for this run and passed as GITEA_TOKEN to the Drone build so the runner's `_gitea_token()` could clone the recipe repo despite the stale bridge secret. The token will be deleted after this run.
Recipe upgrade verified GREEN. NOT merged — for operator review.
autonomic-bot
changed title from chore: upgrade meet to v1.24.0 + livekit v1.13.5 + redis 8.8.1 + nginx 1.31.3 to chore: upgrade lasuite-meet to v1.25.22026-08-07 04:19:23 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Extends this PR with a further bump: meet-frontend + meet-backend + celery v1.24.0 → v1.25.2 (matched set, monorepo tag — they move together).
Image tags
(livekit v1.13.5, redis 8.10.0, nginx 1.31.3, pgautoupgrade 18-debian — all up-to-date, unchanged; carried from the prior v1.24.0 bump already in this PR.)
Upstream release notes
Operator action required
None — no breaking changes to recipe compose/config. Backend runs Django DB migrations on boot (automatic, watch backend logs on upgrade). livekit-server v1.13.5 remains compatible (v1.25.0 upgraded the frontend livekit-client JS library, not the server).
Release (operator, after merge)
abra recipe release lasuite-meet -y
Tested green on the cc-ci recipe CI server (full suite, cold, against this PR head). NOT merged — for operator review.
cc @trav @notplants
!testme
🌻 cc-ci —
lasuite-meet@52af1113❌ failurefull logs · dashboard
!testme
🌻 cc-ci —
lasuite-meet@52af1113✅ passedfull logs · dashboard
chore: upgrade livekit to v1.13.2to chore: upgrade app/backend/celery to v1.23.0, livekit to v1.13.3!testme
🌻 cc-ci —
lasuite-meet@5124fd4e❌ failurefull logs · dashboard
Upgrade diagnosis —
!testmeRED on a stale test (DEFAULT mode: comment, no test edit)Run #1122 (head
5124fd4e): level 3/5 —install✅,upgrade✅,backup_restore✅,lint✅,functional❌.The upgrade itself looks correct
--chaosdeploy: all 7 services 1/1, Django migrationscore.0007→0020applied OK, gunicorn up, celery ready, livekit reports"version": "1.13.3", frontend serves.functionalpasses, includingtest_upgrade_preserves_dataandtest_oidc_password_grant_against_dep_keycloak(OIDC password grant still yields a valid JWT).The single failing test is stale for meet ≥ v1.22.0
Failing test:
tests/lasuite-meet/custom/test_meeting_flow.py::test_create_room_get_livekit_token_and_read_backroom create returned HTTP 401 (expected 201); body={'detail': 'Authentication credentials were not provided.'}POST /api/v1.0/rooms/(Authorization: Bearer <oidc-access-token>).🛂(backend) reject user access tokens on the API. The OIDC user access token is no longer accepted as an API bearer — hence the 401 "Authentication credentials were not provided." This is an intentional security hardening in upstream, not a recipe config gap (there is no env var that re-enables user access tokens on the API; doing so would defeat the fix).test_oidc_password_grant_against_dep_keycloak) only verifies the grant yields a JWT — it does not use the token as an API bearer, which is why it still passes while this test fails. This confirms the failure is specifically the API-auth pattern, not OIDC provisioning.Why this is a stale test (not an upgrade regression)
The test asserts the pre-v1.22.0 auth behavior (OIDC access token → Meet API bearer). meet v1.22.0 deliberately rejects that pattern. The test needs to adopt whatever API-auth mechanism v1.22.0+ expects (e.g. a Meet-issued API token, session-cookie auth, or a different token exchange) — that is a test update, gated by
--with-tests.Recommended next step
Re-run
/recipe-upgrade lasuite-meet --with-teststo also open + verify a cc-ci test-update PR that updatestest_meeting_flow.pyto the v1.22.0+ API-auth mechanism. This recipe PR is otherwise ready (image bumps + config unchanged; recommended operator release:abra recipe release lasuite-meet -y).Nothing was merged. The recipe PR awaits operator review; the test update is opt-in via
--with-tests.chore: upgrade app/backend/celery to v1.23.0, livekit to v1.13.3to chore: upgrade app/backend/celery to v1.24.0, livekit to v1.13.4, nginx to 1.31.3!testme
🌻 cc-ci —
lasuite-meet@8aff5222❌ failurefull logs · dashboard
Upgrade diagnosis —
!testmeRED on a stale test (DEFAULT mode: comment, no test edit)Run #1137 (head
8aff5222, lasuite/meet v1.24.0 + livekit v1.13.4 + nginx 1.31.3): level 3/5 —install✅,upgrade✅,backup_restore✅,lint✅,functional❌ — single test failure, same root cause as the prior diagnosis at v1.23.0 (the API token hardening has not been reverted in v1.24.0).The upgrade itself looks correct
--chaosdeploy on the cc-ci swarm converges cleanly with the new tags: all 7 services 1/1, Django migrationscore.0009→0020+easy_thumbnails/sessions/sitesapplied OK viaAUTO_MIGRATIONS=true, gunicorn up (workers booted), celery ping healthy, livekit reports"version": "1.13.4", nginx 1.31.3 healthy, frontend serves.functionalpasses, includingtest_upgrade_preserves_data,test_oidc_password_grant_against_dep_keycloak, andtest_lasuite_meet_returns_200.The single failing test is stale for meet ≥ v1.22.0
Failing test:
tests/lasuite-meet/custom/test_meeting_flow.py::test_create_room_get_livekit_token_and_read_backroom create returned HTTP 401 (expected 201); body={'detail': 'Authentication credentials were not provided.'}POST /api/v1.0/rooms/(Authorization: Bearer <oidc-access-token>).🛂(backend) reject user access tokens on the API). The OIDC user access token is no longer accepted as an API bearer — hence the 401 "Authentication credentials were not provided." This is an intentional upstream security hardening, not a recipe config gap (the OIDC password-grant path and the health/landing endpoints still pass). The hardening is still in effect in v1.23.0 and v1.24.0.Operator action
!testmego green here, the cc-ci test needs updating (the room-creation functional test must mint an API-acceptable token / use the backend's own auth path rather than a raw OIDC user access token). In DEFAULT mode this skill does NOT modify tests./recipe-upgrade lasuite-meet --with-teststo also open + verify a cc-ci test-update PR that fixes this assertion.This comment is for the v1.24.0 run; the prior comment (run #1122, head
5124fd4e) made the same diagnosis at v1.23.0. NOT merged — for operator review.The stale cc-ci test blocking this PR is now fixed and merged: cc-ci PR #13
(recipe-maintainers/cc-ci#13) replaces the rejected raw-Bearer
auth with the real OIDC authorization-code session login (meet v1.22.0+ API auth hardening).
Verified GREEN: cold full-suite ×1 against THIS PR's head (
8aff5222) with the updated tests —install/upgrade/backup/restore/custom all pass. A fresh
!testmewill now run with the mergedtests. Merging this PR ⇒ green.
chore: upgrade app/backend/celery to v1.24.0, livekit to v1.13.4, nginx to 1.31.3to chore: upgrade meet to v1.24.0, livekit to v1.13.5, redis to 8.10.0, nginx to 1.31.3chore: upgrade meet to v1.24.0, livekit to v1.13.5, redis to 8.10.0, nginx to 1.31.3to chore: pin redis to 8.8.1 (patch over 8.10.0 minor for sidecar cache)chore: pin redis to 8.8.1 (patch over 8.10.0 minor for sidecar cache)to chore: upgrade meet to v1.24.0 + livekit v1.13.5 + redis 8.8.1 + nginx 1.31.3!testme
🌻 cc-ci —
lasuite-meet@8e99426b✅ passedDrone build #1188 — full cold suite GREEN (recipe-ci stage: success). Triggered via direct Drone API (bridge stale-token workaround; scoped GITEA_TOKEN minted for the runner, deleted after).
Final pins on this PR head: meet v1.24.0, livekit v1.13.5, redis 8.8.1, nginx 1.31.3. The stale meeting-flow test (cc-ci PR #13, merged) is now satisfied.
full logs · dashboard
cc-ci !testme verdict: VERDICT=GREEN 🟢
Triggered via the Drone-direct workaround (the ccci-bridge is silently dropping
!testmetriggers due to a stale gitea-bot swarm secret returning HTTP 401 — known infra issue, not fixed here).8e99426b(PR #8 head)A scope-limited gitea token (id 50,
ccci-upgrade-lasuite-meet-20260803) was minted for this run and passed as GITEA_TOKEN to the Drone build so the runner's_gitea_token()could clone the recipe repo despite the stale bridge secret. The token will be deleted after this run.Recipe upgrade verified GREEN. NOT merged — for operator review.
chore: upgrade meet to v1.24.0 + livekit v1.13.5 + redis 8.8.1 + nginx 1.31.3to chore: upgrade lasuite-meet to v1.25.2!testme
🌻 cc-ci —
lasuite-meet@8f473723✅ passedfull logs · dashboard
8f473723f8todc710283edAuto-closed by /recipe-upgrade: its changes are already in upstream main (merged upstream); mirror main re-synced
Pull request closed