test: end-to-end RP+OAuth integration tests

[SalimKayal]

Summary

This chunk adds HTTP-level end-to-end tests that exercise the full integration between resource pools and OAuth2 providers through the Sanic test client. The tests verify that the auto-grant/revoke logic implemented in #1314 and #1317 works correctly from the API surface: users gain and lose resource pool visibility by connecting to and disconnecting from OAuth providers, and admins can swap provider linkages with immediate access changes.

Motivation & Context

While #1314 and #1317 (OAuth connect/disconnect hooks) were tested at the repository layer, we need confidence that the wiring between crc, connected_services, and Authz/SpiceDB holds up through the actual HTTP API. These tests simulate real user journeys:

1. A regular user completes an OAuth2 authorization flow.
2. A resource pool linked to that provider becomes visible to them.
3. Disconnecting removes that visibility.
4. Admin patch operations swap access between user populations correctly.

Design Decisions & Rationale

1. Test Through the Real HTTP Surface

Rather than calling repository methods directly, these tests use SanicASGITestClient to hit the actual endpoints (POST /api/data/resource_pools, GET /api/data/oauth2/providers/{id}/authorize, GET /api/data/oauth2/callback, etc.). This validates:

• Blueprint wiring (e.g., ConnectedServicesRepository._on_oauth2_connected is actually invoked from the callback handler).
• Authz propagation to the visibility layer (GET /api/data/resource_pools filters based on SpiceDB relations).
• Request/response serialization and validation.

2. Reuse the Dummy OAuth Client

Tests in test_resource_pools.py patch app_manager_instance.oauth_http_client_factory.create_client = create_dummy_oauth_client to avoid real external OAuth exchanges. This is the same pattern already used in test_connected_services.py and keeps the tests fast, deterministic, and offline.

3. Shared Helper for OAuth Flow Completion

A local helper _complete_oauth_flow(test_client, provider_id, user_headers) was added in test_resource_pools.py to avoid duplication across the three new tests. It performs the authorize → extract state → callback dance that the dummy OAuth client requires.

4. Isolation via xdist_group("sessions")

Resource pool API tests are marked with @pytest.mark.xdist_group("sessions") to prevent parallel test interference on shared database/cluster state. This follows the existing convention in the test file.

5. Explicit Migration Call

test_connected_services.py tests call run_migrations_for_app("common") at the start because they rely on the full application stack (including Authz/SpiceDB consistency) and the app_manager_instance fixture. This matches patterns from earlier diffs.

Changes

• test/bases/renku_data_services/data_api/test_resource_pools.py

  • Added _complete_oauth_flow helper.
  • Added test_post_resource_pool_with_remote_grants_connected_users:
    • Admin creates provider, regular user connects, admin creates linked RP, user sees it in GET /resource_pools.
  • Added test_delete_resource_pool_removes_access:
    • Same setup, admin deletes RP, user no longer sees it.
  • Added test_patch_resource_pool_remote_change_swaps_access:
    • Two providers (P1, P2), two users, RP linked to P1. User1 sees it, User2 does not. Admin patches RP to P2. User1 loses access, User2 gains it.

• test/bases/renku_data_services/data_api/test_connected_services.py

  • Added imports: run_migrations_for_app, KindCluster.
  • Added test_oauth_callback_adds_user_to_rp:
    • Admin creates provider and linked private RP. Regular user cannot see RP. User completes OAuth callback. User can now see RP.
  • Added test_delete_oauth_connection_removes_rp_access:
    • Same setup, user completes OAuth callback and can see RP. User deletes their OAuth connection. User can no longer see RP.

Behavioral Changes (Verified by Tests)

This PR contains no new production code; it only adds tests. However, it verifies the following behavioral changes introduced by #1314 and #1317:

Observable Behavior: OAuth Connection Drives RP Visibility

• Before the feature: A regular user could only see a private resource pool if an admin explicitly added them as a member.
• After the feature: A regular user automatically sees private resource pools whose remote.provider_id matches an OAuth provider they are connected to. This is visible at the API level via GET /api/data/resource_pools.

Observable Behavior: Disconnect Immediately Revokes Visibility

• Before the feature: Revoking access required an admin to manually remove the user from the resource pool.
• After the feature: A user who deletes their OAuth2 connection (DELETE /api/data/oauth2/connections/{id}) immediately loses visibility of all resource pools tied to that provider.

Observable Behavior: Provider Swap Atomically Exchanges Populations

• Before the feature: Changing a resource pool's provider had no membership side effects.
• After the feature: Patching remote.provider_id from P1 to P2 causes all connected P1 users to lose access and all connected P2 users to gain access in a single operation.

---

PR Stack

• base: feat: automatic resource pool viewer access via OAuth2 provider linkage #1315
  • feat: auto-grant/revoke resource pool viewer access on CRUD based on OAuth2 provider linkage #1314
  • feat: sync resource pool viewer access on OAuth2 connect and disconnect #1317
  • this

[leafty]

This test feels unnecessary. The OAuth 2.0 automation is not playing a role since deleting a resource pool deletes said resource pool.

[SalimKayal]

removed.

[coveralls]

Coverage Report for CI Build 27261227871

Warning

No base build found for commit 09ef102 on salimkayal-feat-resource-pools-access-through-integration.
Coverage changes can't be calculated without a base build.
If a base build is processing, this comment will update automatically when it completes.

Coverage: 86.311%

Details

• Patch coverage: No coverable lines changed in this PR.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

Requires a base build to compare against. How to fix this →

---

Coverage Stats

Relevant Lines:	31179
Covered Lines:	26911
Line Coverage:	86.31%
Coverage Strength:	1.5 hits per line

---

💛 - Coveralls