[fadi-george]

Description

Replaces #2780, which could not be retargeted from its old stack.

One Line Summary

When the sessions API flag is on, enqueue a CreateSessionOperation when a new session starts.

Details

Motivation

Part of the SDK Sessions stack (SDK-5382). New sessions need a POST /apps/{app_id}/sessions, sent through the persistent queue added in #2794 (base of this one).

Scope

• SessionService enqueues one CreateSessionOperation on the new-session path when the session's captured usesSessionsApi is true. It carries the app ID, the session's local ID, the pinned OneSignal and push subscription IDs, start_time, and a new idempotency key.
• Enqueued on SerialIO where the session is set up, so there is exactly one create per session, consistent with the pinned IDs.
• Resuming within sessionFocusTimeout (30 s) continues the session and sends no create. Cold start still ends a persisted valid session before starting a new one.
• Skipped with a warning if the pinned OneSignal ID or subscription ID is missing.
• Flag off: nothing new is sent. The legacy TrackSessionStartOperation is unchanged in both cases; turning off legacy reporting is SDK-5388.
• Aligns the create body with the current spec: device_type is renamed to subscription_type and sent as the subscription type string (AndroidPush, FireOSPush, HuaweiPush), like outcomes/measure. idempotency_key drops the local- prefix so it is a bare UUID.
• Not included: direct_attribution_id (SDK-5399), session end (SDK-5390).

Testing

Unit testing

Added SessionServiceTests cases: create fields when the flag is on, a new create and idempotency key per session, no create on resume within the timeout, cold start with a persisted valid session, no create when the flag is off, and no create without a push subscription ID. Updated backend and executor tests for subscription_type and the UUID idempotency key.

spotlessCheck, detekt, testDebugUnitTest, and assembleRelease pass locally.

Manual testing

Not tested on device yet; end-to-end verification is planned in the Android Rollout & QA ticket (SDK-5405).

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
• I have reviewed this PR myself, ensuring it meets each checklist item

🤖 Generated with Claude Code

[github-actions]

📊 Diff Coverage Report

Diff Coverage Report (Changed Lines Only)

Gate: aggregate coverage on changed executable lines must be ≥ 80% (JaCoCo line data for lines touched in the diff).

Changed Files Coverage

• ISessionsBackendService.kt: 1/1 touched executable lines (100.0%) (1 touched lines in diff)
• SessionsBackendService.kt: 1/1 touched executable lines (100.0%) (1 touched lines in diff)
• SessionService.kt: 17/17 touched executable lines (100.0%) (30 touched lines in diff)
• CreateSessionOperation.kt: 1/1 touched executable lines (100.0%) (1 touched lines in diff)
• SessionOperationExecutor.kt: 1/1 touched executable lines (100.0%) (2 touched lines in diff)

Overall (aggregate gate)

21/21 touched executable lines covered (100.0% — requires ≥ 80%)

📥 View workflow run

[abdulraqeeb33]

The create path is right: one enqueue per new session, a resume sends none, and the idempotency key is a bare UUID.

The body still needs device_type as an integer. See the inline.