Skip to content

[MOB - 11292] - Process Pending Action First #906

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 6, 2025

Conversation

Ayyanchira
Copy link
Member

@Ayyanchira Ayyanchira commented Apr 22, 2025

🔹 Jira Ticket(s) if any

✏️ Description

SDK calls getMessages, registerDevice Apis when initializing. When push track happens, initialization also includes push track in the sequence. However, in current sequence, process pending actions which lead to push tracking was done after lifecycle handling was done where getMessages and registerDevice happens.

JWT mechanism only retries the first failed call. Thus push track open would not get retried as the first failing call would be getMessages and that would be retried when JWT failure occurred.

This PR will change the sequence and make sure Push related APIs are first in line so they are retried instead of getMessages. This solution is better than current one as the sequence of api calls will more align with iOS behavior and we will retain a tracking metric by retrying those instead of getMessages which anyways a lesser important API call.

A true caching mechanism still doesn't not exist where all the requests are cached and retried but this definitely should unblock the customer

Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This PR reorders SDK initialization to process pending push actions before registering activity lifecycle callbacks, ensuring push tracking occurs earlier for improved retry behavior with JWT.

  • Moved the processPendingAction call to an earlier point in initialization.
  • Removed the duplicate or later call to processPendingAction.
Comments suppressed due to low confidence (2)

iterableapi/src/main/java/com/iterable/iterableapi/IterableApi.java:621

  • Ensure that moving processPendingAction earlier does not impact any initialization dependencies later in the method.
IterablePushNotificationUtil.processPendingAction(context);

iterableapi/src/main/java/com/iterable/iterableapi/IterableApi.java:621

  • The duplicate call removal appears intentional; verify that all necessary pending actions are handled before lifecycle callbacks are registered.
IterablePushNotificationUtil.processPendingAction(context);

SDK calls getMessages, registerDevice Apis when initializing. When push track happens, initialization also includes push track in the sequence. However, in current sequence, process pending actions which lead to push tracking was done after lifecycle handling was done where getMessages and registerDevice happens.

JWT mechanism only retries the first failed call. Thus push track open would not get retried as the first failing call would be getMessages and that would be retried when JWT failure occurred.

This PR will change the sequence and make sure Push related APIs are first in line so they are retried instead of getMessages. This solution is better than current one as the sequence of api calls will more align with iOS behavior and we will retain a tracking metric by retrying those instead of getMessages which anyways a lesser important API call.

A true caching mechanism still doesn't not exist where all the requests are cached and retried but this definitely should unblock the customer
Copy link
Contributor

@evantk91 evantk91 left a comment

Choose a reason for hiding this comment

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

LGTM

@Ayyanchira Ayyanchira merged commit 18df7da into master May 6, 2025
3 checks passed
@Ayyanchira Ayyanchira deleted the mob-11292-Push-retry-when-jwt-retry branch May 6, 2025 15: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
2 participants