LOOPIN-73B — Add Authenticated Staging API, Media and WebSocket Smoke Suite

[shaig-mahmudov]

Type: CI/CD / Testing / Deployment Validation
Priority: High

Description

Add a post-deployment smoke suite that validates critical authenticated Loopin API behavior against the deployed staging environment.

The suite must verify authentication, Events, Groups, media storage and authenticated WebSocket connectivity using isolated staging test data.

This issue depends on LOOPIN-73A and assumes a healthy staging deployment is already available.

Dependencies

• LOOPIN-73A is completed.
• A staging PostgreSQL database is available.
• A staging Redis instance is available.
• A staging S3-compatible object-storage bucket is available.
• A dedicated staging smoke-test user is provisioned.
• A secure short-lived authentication mechanism is defined.

Authentication Strategy

Use a dedicated staging smoke-test identity.

The suite must obtain a short-lived authentication token through an explicitly documented secure mechanism.

Requirements:

• Do not enable the development login endpoint in staging.
• Do not commit a JWT or Google token.
• Do not store a long-lived user token in GitHub secrets.
• Do not use a real personal account.
• Do not weaken production or staging authentication rules.
• The smoke user must exist in the staging database before protected endpoint validation begins.

The selected authentication mechanism must be documented before implementation.

Scope

1. Post-deployment smoke runner

Create a reusable smoke-test script or small test runner, for example:

scripts/ci/run-staging-smoke.sh

The runner should receive:

• staging base URL;
• short-lived access token or secure token acquisition configuration;
• smoke-test user information;
• required timeout settings.

The runner must fail on the first critical validation failure while still performing cleanup where possible.

2. Authentication validation

Verify:

• an unauthenticated request to a protected endpoint is rejected;
• an invalid bearer token is rejected;
• the staging smoke user can obtain or use a valid short-lived token;
• a protected current-user endpoint succeeds;
• the authenticated user identity matches the expected smoke user.

3. Events smoke flow

Using the staging smoke user:

• create a valid event;
• capture the created event ID;
• read the created event;
• update it where supported;
• verify it appears through the relevant API flow;
• delete or cancel it during cleanup.

Use unique names containing the workflow run ID or commit SHA to prevent collisions.

Do not depend on pre-existing application data.

4. Groups smoke flow

Using the authenticated smoke user:

• create a group associated with the smoke event where required;
• capture the group ID;
• read the group;
• verify authorized group access;
• delete or archive the group during cleanup.

The suite must avoid leaving persistent test groups or memberships behind.

5. Media smoke flow

Validate the complete real storage flow:

1. request a presigned upload URL;
2. upload a small generated test image to the presigned URL;
3. complete the media upload;
4. verify the media record reaches the expected uploaded state;
5. delete the uploaded media during cleanup.

The test must use the staging object-storage bucket.

Do not mock S3 or MinIO in this suite.

Configure all required staging storage values, including where applicable:

• STORAGE_ENDPOINT
• STORAGE_PRESIGN_ENDPOINT
• STORAGE_REGION
• STORAGE_BUCKET
• STORAGE_ACCESS_KEY
• STORAGE_SECRET_KEY
• STORAGE_PATH_STYLE_ACCESS

Do not print presigned URLs or credentials in logs.

6. WebSocket smoke flow

Validate the deployed SockJS/STOMP endpoint.

The smoke client must:

• establish a connection to /api/ws;
• send an authenticated STOMP CONNECT;
• subscribe to an authorized group topic;
• verify the subscription is accepted;
• disconnect cleanly;
• establish a new authenticated connection;
• subscribe again successfully.

The test should verify that a disconnected client can reconnect and create a new authenticated session.

Do not wait for the full infrastructure timeout merely to test reconnect behavior.

Frontend automatic reconnect UX is outside this issue.

7. Cleanup

Cleanup must run even when part of the smoke suite fails.

Remove or transition all temporary resources created by the suite:

• events;
• groups;
• memberships where applicable;
• media database records;
• uploaded storage objects.

Use unique run identifiers so abandoned data can be found and removed manually.

Cleanup errors should be reported without hiding the original validation failure.

8. GitHub Actions integration

Run this suite after LOOPIN-73A health checks pass.

The workflow must:

• pass the staging URL securely;
• obtain or inject the short-lived smoke authentication token;
• execute the smoke suite;
• mark the deployment validation as failed when any required flow fails;
• upload sanitized smoke-test logs and response summaries;
• include the deployed commit SHA and revision in the result summary.

Do not run authenticated smoke flows before readiness is UP.

9. Diagnostics

On failure, record sanitized information such as:

• failing smoke step;
• endpoint path;
• HTTP status;
• response body with sensitive fields removed;
• created resource IDs where safe;
• WebSocket connection stage;
• cleanup result.

Never log:

• bearer tokens;
• Google ID tokens;
• storage credentials;
• presigned upload URLs;
• authorization headers;
• secret environment variables.

10. Documentation

Update staging documentation with:

• smoke-user provisioning;
• authentication-token strategy;
• required storage configuration;
• supported smoke flows;
• cleanup behavior;
• local execution instructions;
• failure investigation steps;
• limitations of the WebSocket reconnect validation.

Acceptance Criteria

• The smoke suite runs only after staging readiness is UP.
• Unauthenticated and invalid-token requests are rejected correctly.
• A dedicated staging smoke user can access protected endpoints.
• A complete authenticated Event flow succeeds.
• A complete authenticated Group flow succeeds.
• A real media object is uploaded through a presigned URL.
• Media completion succeeds against staging object storage.
• The uploaded media object is removed during cleanup.
• An authenticated STOMP client can connect and subscribe.
• The client can disconnect, reconnect and subscribe again.
• Created events, groups and media are cleaned up.
• Failure in any required flow fails the deployment-validation job.
• Sanitized diagnostic logs are available after failure.
• Tokens, credentials and presigned URLs are never printed.
• The deployed commit SHA and revision are included in the smoke-test summary.
• The authentication and smoke-test setup is documented.

Deliverables

• Reusable authenticated staging smoke-test runner
• Secure staging smoke-user authentication flow
• Events smoke flow
• Groups smoke flow
• Real media upload and cleanup flow
• STOMP connection and reconnect validation
• Failure diagnostics
• Test-data cleanup
• Updated deployment and staging documentation

Out of Scope

• Frontend browser E2E tests
• Testing the frontend reconnect UI
• Load or performance testing
• Production smoke testing
• Automatic production promotion
• Long-duration WebSocket soak tests
• Testing every API endpoint
• Enabling development login in staging
• Using mocked PostgreSQL, Redis or object storage