Repository navigation
[SDK-707] Replace request AsyncTask with SDK executor - #1096
franco-zalamena-iterable wants to merge 6 commits into
Conversation
rtlsilva
left a comment
There was a problem hiding this comment.
The ticket says the full suite should contain no ShadowPausedAsyncTask references, but this head still has six references in BaseTest, IterableApiIntegrationTest, and IterableApiGetAndTrackDeepLinkTest.
Suggest removing the remaining shadow dependencies and synchronizing those tests through the new request seam or the appropriate executor/looper primitives.
| healthMonitor, | ||
| classification); | ||
| taskScheduler = new TaskScheduler(taskStorage, taskRunner); | ||
| taskScheduler = new TaskScheduler(taskStorage, taskRunner, requestDispatcher); |
There was a problem hiding this comment.
The dispatcher is passed to TaskScheduler, but stored requests do not use it: IterableTaskRunner still invokes IterableRequestTask.executeApiRequest() directly on its own HandlerThread. A persisted request can therefore overlap with or be overtaken by immediate requests running on IterableExecutors.serial(), so this PR's stated serialization of offline requests does not hold.
Suggest routing task-runner network execution through the same request queue and covering stored-versus-immediate ordering.
There was a problem hiding this comment.
Stored requests now use an SDK dispatcher, but the shared-ordering part of this thread has regressed in b6d0d841: immediate requests in offline mode use requestDispatchers.online() (now an 8-thread pool) while stored tasks use the separate requestDispatchers.offline() lane, and the submission-order test was removed. These paths can overlap or overtake one another again, and the PR description still says these requests are serialized.
This also isn't quite the pre-migration behaviour: on master, offline-mode immediate requests went through AsyncTask.execute() (the serial executor), and only OnlineRequestProcessor used THREAD_POOL_EXECUTOR. Routing them to online() makes them concurrent with each other as well.
If matching pre-migration concurrency is the goal, suggest keeping offline-mode immediate requests serial, updating the PR contract, and adding coverage for the intended cross-lane behavior.
Otherwise, suggest keeping both paths on one ordered dispatcher.
419a140 to
ffe5431
Compare
|
Review feedback is addressed in ffe5431:
Verification on this commit:
Requesting another review. |
ffe5431 to
e697ce6
Compare
|
Updated SDK-707 after the stack rebase, preserving all prior review fixes and addressing the concurrency concern:
New focused coverage proves that the client routes ordinary and push requests to the correct lanes, a blocked online request does not serialize a second online request, and blocked online work does not delay push work. The synchronization uses latches with no sleeps. Verification:
CI is currently running on e697ce6. Ready for another review. |
|
Follow-up from the first CI run: the new concurrency and routing tests passed. CI exposed a separate Mockito spy race in IterableFirebaseMessagingServiceTest, where a pending initialization callback could call getDebugMode while the test was stubbing getInAppManager. Commit 2f34558 now drains initialization callbacks before creating the spy and uses safe doReturn stubbing. The affected service tests and executor tests pass locally; replacement CI is running. |
|
Final CI follow-up for 2f34558:
The branch is now waiting only on reviewer approval and the known external image-test failure. |
jferrao-itrbl
left a comment
There was a problem hiding this comment.
Great work @franco-zalamena-iterable . LGTM.
It might be worth checking the failing test though it seems unrelated with these changes.
2f34558 to
7ca9382
Compare
7ca9382 to
b6d0d84
Compare
rtlsilva
left a comment
There was a problem hiding this comment.
Reopened a discussion, no other findings.
📝 Summary
Moves API request execution from AsyncTask to an SDK-owned serial dispatcher while preserving callback threading and existing retry behavior.
🎟️ Jira Ticket: SDK-707
📖 Description
This stacked PR builds on SDK-706 and:
🧪 How to test?
The standalone inbox-customization sample remains blocked by its pre-existing Kotlin 1.8 incompatibility with the data object declaration in iterableapi-ui.
🧾 Changelog
Updated the existing Unreleased executor entry to include API requests and API response callback threading.
📹 Loom recording if applicable
Not applicable.
🐞 Github Issues solved
None.
📚 Docs PR if applicable
No documentation PR required.