Skip to content

feat: [SDK-5383] enqueue a session create when a new session starts - #1770

Closed
fadi-george wants to merge 9 commits into
fadi/sdk-5379from
fadi/sdk-5383
Closed

fadi-george wants to merge 9 commits into
fadi/sdk-5379from
fadi/sdk-5383

Conversation

@fadi-george

@fadi-george fadi-george commented Oct 9, 2026 •

Copy link
Copy Markdown
Collaborator

Description

One Line Summary

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

Details

Motivation

Part of the iOS SDK Sessions stack (SDK-5383). New sessions need a POST /apps/{app_id}/sessions, sent by the session executor added in #1768 (base of this one). Android counterpart: OneSignal/OneSignal-Android-SDK#2780.

Scope

  • OSSessionService.startNewSession enqueues one create when the session's captured usesSessionsApi is true, through new enqueueSessionCreate / enqueueSessionUpdate requirements on OSSessionUserProvider. The User module turns it into a session Delta for the operation repo. It carries the session's local ID (also the idempotency key), start_time, and the pinned OneSignal and push subscription IDs.
  • Runs on the existing new-session path (OneSignal.m shouldStartNewSession), so the 30 s threshold, cold-start behavior, and privacy-consent gates are unchanged. Resuming within the threshold sends no create.
  • Unlike Android, a create with missing IDs is still enqueued; the executor holds it until the backend assigns them.
  • Flag off: nothing is enqueued. The legacy session start is unchanged.
  • Not included: direct_attribution_id (SDK-5399), session end (SDK-5391).

Testing

Unit testing

Added OSSessionServiceTests cases: the create is enqueued with the session's start time and pinned IDs, a separate create per session, no create on resume, and none when the flag is off. Enqueueing a session Delta is covered in OSSessionOperationExecutorTests from #1768.

The full UnitTestApp scheme passes locally, apart from the UserConcurrencyTests.testSubscriptionExecutorConcurrency flake. SwiftLint reports no new violation types.

Manual testing

Not tested on device yet; end-to-end verification is planned in the iOS rollout and QA ticket.

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

fadi-george and others added 4 commits October 9, 2026 13:25
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…length

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
fadi-george and others added 5 commits October 9, 2026 17:10
Replace the standalone session request queue with OSRequestCreateSession /
OSRequestUpdateSession and an OSSessionOperationExecutor registered with
OSOperationRepo, persisted like the other executors. Session requests are
retried in the same run on a later flush once their backoff passes, honoring
Retry-After, up to 5 answered failures. The post-create delay uses
OSNewRecordsState. The OSCore sessions backend service is folded into the
executor and request classes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The sessions API takes no user JWT, so session Deltas are no longer dropped
as anonymous by the operation repo, and the session executor keeps its
requests through the anonymous purge.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…turn

Add OSOperationRepo.retryNow, which ends executors' failure backoff early
but still waits out a backend Retry-After, then flushes. OSOperationRetryTrigger
calls it when the app comes to the foreground and when a network becomes
available while foregrounded, driven by OneSignalTracker's focus events.
Executors opt in through OSOperationExecutor.retryNow; only the session
executor does so far. Mirrors Android's OperationRetryTrigger.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ated

Under required Identity Verification an anonymous user is never created, so a
session create still waiting for its onesignal_id can never be sent. The
anonymous purge now drops those creates and their updates, matching Android.
Anonymous users that already have a onesignal_id keep their requests.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
OSSessionService.startNewSession enqueues the create through the session
user provider when the session uses the sessions API. The User module turns
it into a session Delta for the operation repo.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

@abdulraqeeb33 abdulraqeeb33 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving.

One create per new session, nothing on resume, nothing when the flag is off. directAttributionId is always nil. Android #2783 is the notification-attribution piece, and this stack has no iOS counterpart yet.

persist()
}
if newRecord.usesSessionsApi {
userProvider.enqueueSessionCreate(newRecord, directAttributionId: nil)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

directAttributionId is always nil. Fine for this PR. Android #2783 attaches a notification open, and there is no iOS PR for that yet.

@fadi-george

Copy link
Copy Markdown
Collaborator Author

Closing, the session queue PR (#1768) was redone on top of #1775. Will reopen session start and end on top of it.

An error occurred while trying to automatically change base from fadi/sdk-5379 to new-session-events October 19, 2026 17:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants