Release 8.2.0

[piyush-kukadiya]

Summary by CodeRabbit

Release Notes

• New Features

  • Added on-demand inbox fetch via fetchInbox() method with 5-minute throttling
  • Pull-to-refresh gesture support in built-in App Inbox UI
  • Cross-device App Inbox synchronization and message deduplication
  • Automatic suppression of duplicate notification viewed/clicked events across devices
  • Display Unit element click event tracking

• Dependencies

  • Added androidx.swiperefreshlayout library support

[francispereira]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[github-actions]

Code Coverage Debug

Overall Project	68.37% -0.55%	✅
Files changed	86.93%	✅

Module	Coverage
clevertap-core	67.3% -0.62%	✅

Files

Module	File	Coverage
clevertap-core	InboxV2EventBuilder.kt	100%	✅
	FetchThrottle.kt	100%	✅
	CallResult.kt	100%	✅
	EventRequestBody.kt	100%	✅
	NetworkScope.kt	100%	✅
	CTDisplayUnitController.java	100%	✅
	BaseAnalyticsManager.java	100%	✅
	Constants.java	100%	✅
	EventSuppressor.kt	100%	✅
	InboxDeleteCoordinator.kt	100%	✅
	InboxV2Merger.kt	99.42% -0.58%	✅
	InboxV2Response.kt	98.48% -1.52%	✅
	CleverTapFactory.kt	96.38% -0.27%	✅
	InboxV2Fetcher.kt	96.32% -3.68%	✅
	InboxFetchCall.kt	95.65% -4.35%	✅
	CtApi.kt	95.41% -0.95%	✅
	DBAdapter.kt	94.19%	✅
	InboxV2Bridge.kt	91.43% -8.57%	✅
	FetchTrigger.kt	90.48% -4.76%	✅
	InboxV2DeliverySource.kt	90.48% -4.76%	✅
	InboxMessageSource.kt	90.48% -4.76%	✅
	InboxDeleteCall.kt	88.27% -11.73%	✅
	AnalyticsManager.java	87.8% -1.09%	✅
	CTInboxController.java	86.88% -3.9%	✅
	InboxMessageDAOImpl.kt	83.18% -5.33%	✅
	CTMessageDAO.java	82.66%	✅
	InboxPendingActionsDAO.kt	79.58% -20.42%	✅
	CoreState.kt	78.22%	✅
	CtDatabase.kt	64.32%	✅
	LoginController.java	59.81%	✅
	ActivityLifeCycleManager.java	53.71%	✅
	CleverTapAPI.java	31.22% -1.56%	❌
	ControllerManager.java	24.59% -20.08%	❌
	DisplayUnitResponse.java	10.48% -49.05%	❌

[coderabbitai]

Walkthrough

Implements App Inbox V2 (fetch/delete, throttling, DB schema v7, controller processing, delete coordinator, bridge, tests), introduces DisplayUnitCache and element-level click analytics, adds swipe-to-refresh in inbox UI, wires lifecycle/login triggers, updates docs/examples, and bumps SDK to 8.2.0.

Changes

Inbox V2 sync and Display Unit cache integration

Layer / File(s)	Summary
Inbox V2 + Display Units end-to-end clevertap-core/..., docs/*, sample/..., templates/*, gradle/*, CHANGELOG.md, README.md	Adds Inbox V2 network calls, throttle/bridge, DB schema and DAOs, controller processing and delete coordinator, UI swipe-to-refresh, DisplayUnitCache API and element-click events, lifecycle/login wiring, extensive tests, and version/docs updates to 8.2.0.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant App as App/Fragment
  participant API as CleverTapAPI
  participant Bridge as InboxV2Bridge
  participant Fetcher as InboxV2Fetcher
  participant Endpoint as CtApi
  participant Resp as InboxV2Response
  participant DB as DBAdapter/DAOs
  participant Cntrl as CTInboxController

  App->>API: fetchInbox(callback)
  API->>Bridge: submit(USER_INITIATED, callback)
  Bridge->>Fetcher: fetch(USER_INITIATED)
  Fetcher->>Endpoint: POST /inbox/v2/getMessages
  Endpoint-->>Fetcher: 200 JSON
  Fetcher->>Resp: processResponse(JSONObject)
  Resp->>DB: upsert/sweep/update
  Resp->>Cntrl: processV2Response(FETCH)
  Fetcher-->>Bridge: Success
  Bridge-->>App: callback(true)

Loading

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~120 minutes

Possibly related PRs

• CleverTap/clevertap-android-sdk#995: Overlaps core Inbox V2 wiring (bridge/fetcher/response) and controller changes present here.
• CleverTap/clevertap-android-sdk#867: Related DBAdapter refactors aligning with DAO-based delegations added in this PR.
• CleverTap/clevertap-android-sdk#829: Both modify ActivityLifeCycleManager resume flow, intersecting with this PR’s Inbox V2 fetch submission.

Suggested labels

Reviewed chained PRs

Suggested reviewers

• deeksha-rgb

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch develop

[coderabbitai]

Actionable comments posted: 14

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

clevertap-core/src/main/java/com/clevertap/android/sdk/db/CtDatabase.kt (1)

67-83: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Guard v1→v7 migration from duplicate-column ALTER.

When oldVersion == 1, Line 73 recreates inboxMessages with source and index_state already present, then Line 107 and Line 108 try to add those columns again, which can fail upgrade with a duplicate-column SQL error.

💡 Suggested fix

-        if (oldVersion < 7) {
+        if (oldVersion < 7) {
             executeStatement(db, CREATE_INBOX_PENDING_DELETES_TABLE)
             executeStatement(db, CREATE_INBOX_PENDING_READS_TABLE)
-            executeStatement(db, ALTER_INBOX_MESSAGES_ADD_SOURCE)
-            executeStatement(db, ALTER_INBOX_MESSAGES_ADD_INDEX_STATE)
+            if (oldVersion != 1) {
+                executeStatement(db, ALTER_INBOX_MESSAGES_ADD_SOURCE)
+                executeStatement(db, ALTER_INBOX_MESSAGES_ADD_INDEX_STATE)
+            }
         }

Also applies to: 104-109, 309-333

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@clevertap-core/src/main/java/com/clevertap/android/sdk/db/CtDatabase.kt`
around lines 67 - 83, The migration for oldVersion == 1 recreates inboxMessages
via CREATE_INBOX_MESSAGES_TABLE but later runs ALTER TABLE ADD COLUMN for
"source" and "index_state", causing duplicate-column errors; update
CtDatabase.kt to check whether those columns already exist before running the
ALTERs (e.g. query PRAGMA table_info('inboxMessages') or similar helper) and
only call executeStatement to add columns if they are absent; apply the same
guard where the same ALTERs occur (the blocks referencing
CREATE_INBOX_MESSAGES_TABLE, CREATE_INBOX_MESSAGES_TABLE-related ALTERs and the
code areas around the other occurrences noted) so the v1→v7 path skips duplicate
ADD COLUMN statements.

clevertap-core/src/main/java/com/clevertap/android/sdk/response/DisplayUnitResponse.java (1)

85-89: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Empty payload should clear cache instead of returning early.

Line 85 currently returns for messages.length() == 0, so cache.updateDisplayUnits(...) and callback notification never run. If server sends [], stale display units can persist.

💡 Proposed fix

-        if (messages == null || messages.length() == 0) {
+        if (messages == null) {
             logger.verbose(config.getAccountId(),
-                    Constants.FEATURE_DISPLAY_UNIT + "Can't parse Display Units, jsonArray is either empty or null");
+                    Constants.FEATURE_DISPLAY_UNIT + "Can't parse Display Units, jsonArray is null");
             return;
         }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@clevertap-core/src/main/java/com/clevertap/android/sdk/response/DisplayUnitResponse.java`
around lines 85 - 89, The handler in DisplayUnitResponse currently returns early
when messages is empty, leaving stale data; instead, detect messages == null
versus messages.length()==0 and for the empty-array case call
cache.updateDisplayUnits(...) with an empty list (or equivalent clear), invoke
the display-units callback/notification path just as with a populated payload,
and log the empty payload event via logger.verbose; keep the null check
returning early but ensure messages.length()==0 triggers cache clearing and
callback invocation so stale units are removed.

🧹 Nitpick comments (5)

clevertap-core/src/main/java/com/clevertap/android/sdk/inbox/CTInboxController.java (2)

601-605: 💤 Low value

Clarify the negative TTL branch semantics.

The condition ttl > 0L ? ttl : nowSeconds + PENDING_DELETE_DEFAULT_TTL_SECONDS applies the default TTL when ttl is negative, which seems like an unexpected edge case. A brief comment explaining when this could occur (e.g., legacy data, parsing errors) would improve maintainability.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@clevertap-core/src/main/java/com/clevertap/android/sdk/inbox/CTInboxController.java`
around lines 601 - 605, The negative-TTL branch in resolvePendingActionExpiry
(method) is unclear: add a concise comment above the ternary that explains why
dao.getExpires() might be negative (e.g., legacy/formatting/parsing errors or
sentinel values) and that in such cases we intentionally apply
PENDING_DELETE_DEFAULT_TTL_SECONDS to avoid immediate expiry; reference
CTMessageDAO.getExpires() and the PENDING_DELETE_DEFAULT_TTL_SECONDS constant in
the comment so future readers understand the fallback semantics.

---

141-171: ⚖️ Poor tradeoff

Potential TOCTOU between V2 partitioning and the actual delete.

The code reads messages under messagesLock (lines 147-158), then releases the lock to write pending deletes to DB (line 161), then acquires inboxControllerLock to perform the delete (line 163). If another thread modifies messages between these locks, the V2 partition could be stale.

This is likely safe in practice because inbox operations run through the async executor, but the window exists. Consider documenting the serialization assumption or restructuring to hold the lock continuously.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@clevertap-core/src/main/java/com/clevertap/android/sdk/inbox/CTInboxController.java`
around lines 141 - 171, Partitioning V2 messages currently happens under
messagesLock then releases it before writing pendingRows and calling
_deleteMessagesForIds, allowing a TOCTOU; to fix, perform the V2 partitioning,
pendingRows construction (resolvePendingActionExpiry), the
dbAdapter.addPendingDeletes(...) call, and the _deleteMessagesForIds(messageIDs)
invocation while holding the same higher-level inbox controller lock
(ctLockManager.getInboxControllerLock()) so the sequence (v2Messages/pendingRows
creation -> db write -> deletion ->
callbackManager._notifyInboxMessagesDidUpdate()) is atomic; adjust
synchronization so messagesLock work happens inside that controller lock or
acquire controller lock first, then iterate messages to build
v2Messages/pendingRows, call dbAdapter.addPendingDeletes, call
_deleteMessagesForIds, and finally call inboxDeleteCoordinator.syncDelete if
needed.

clevertap-core/src/main/java/com/clevertap/android/sdk/db/dao/InboxPendingActionsDAO.kt (2)

167-174: 💤 Low value

Return value check may incorrectly report failure for duplicate inserts.

insertWithOnConflict with CONFLICT_IGNORE returns -1 when a constraint violation causes the insert to be skipped. The check >= 0 will return false in this case, but for idempotent semantics (the row already exists), this should arguably be considered success.

If intentional (only report success for newly inserted rows), consider documenting this behavior. Otherwise, for true idempotency:

Proposed fix for idempotent semantics

         return try {
-            dbHelper.writableDatabase.insertWithOnConflict(
+            val result = dbHelper.writableDatabase.insertWithOnConflict(
                 Table.INBOX_PENDING_DELETES.tableName, null, cv, SQLiteDatabase.CONFLICT_IGNORE
-            ) >= 0
+            )
+            // -1 means either error or conflict-ignored; for idempotency, we only
+            // care that no exception was thrown.
+            true
         } catch (e: SQLiteException) {

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@clevertap-core/src/main/java/com/clevertap/android/sdk/db/dao/InboxPendingActionsDAO.kt`
around lines 167 - 174, The current insert in InboxPendingActionsDAO uses
dbHelper.writableDatabase.insertWithOnConflict(...,
SQLiteDatabase.CONFLICT_IGNORE) and treats any -1 result as failure; change the
success check to treat -1 (constraint-ignored duplicate) as success for
idempotent semantics: capture the insertWithOnConflict return into a variable
(e.g., result) and return true if result >= 0 OR result == -1; keep the
SQLiteException catch/log using logger.verbose for Table.INBOX_PENDING_DELETES
to preserve error handling.

---

193-200: 💤 Low value

Same return value consideration applies to addPendingRead.

This has the same >= 0 check pattern. If the idempotent semantics fix is applied to addPendingDelete, apply it here too for consistency.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@clevertap-core/src/main/java/com/clevertap/android/sdk/db/dao/InboxPendingActionsDAO.kt`
around lines 193 - 200, The addPendingRead method currently treats insert result
as successful with ">= 0"—make it consistent with the idempotent semantics
applied to addPendingDelete by changing the success check to use "> 0" instead;
update the return expression in the insert block that references
Table.INBOX_PENDING_READS.tableName so the method returns true only for a
positive rowId while preserving the existing SQLiteException catch and logging.

clevertap-core/src/main/java/com/clevertap/android/sdk/inbox/EventSuppressor.kt (1)

24-30: ⚖️ Poor tradeoff

Memory consideration: unbounded key growth.

The ConcurrentHashMap has no eviction mechanism. If unique keys accumulate over time (e.g., unique message IDs across sessions), the map will grow indefinitely. For inbox event suppression where keys are bounded by message count, this is likely acceptable. If this class is reused for other purposes with unbounded key spaces, consider adding TTL-based eviction or a size cap.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@clevertap-core/src/main/java/com/clevertap/android/sdk/inbox/EventSuppressor.kt`
around lines 24 - 30, The ConcurrentHashMap lastSeen used by shouldSuppress can
grow unbounded for unbounded key spaces; update the implementation to prevent
memory leak by adding eviction: either replace lastSeen with a bounded cache
with TTL (e.g., use a ConcurrentLinkedHashMap/Guava Cache or an LRU with
maximumSize and expireAfterWrite using the same windowMs) or implement periodic
cleanup of entries older than windowMs when calling shouldSuppress; ensure
symbols referenced are lastSeen, shouldSuppress, windowMs and preserve
thread-safety for concurrent access.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@clevertap-core/src/main/java/com/clevertap/android/sdk/AnalyticsManager.java`:
- Around line 1114-1120: The code dereferences data via data.getMessageId()
before verifying data is non-null, which can throw an NPE; update the logic in
AnalyticsManager so you first check if data == null (or otherwise guard) and
return early, then call data.getMessageId(); ensure the null check happens
before using data in isV2InboxMessage(...) and before calling
config.getLogger().verbose(...) so all references to data (getMessageId,
isV2InboxMessage) occur only after the null guard.

In `@clevertap-core/src/main/java/com/clevertap/android/sdk/CleverTapAPI.java`:
- Around line 2372-2374: The async path in messageDidShow calls
getInboxMessageForId(inboxMessage.getMessageId()) and immediately uses the
result (CTInboxMessage message) without null-checking, causing an NPE if the
message was removed; update the code in the messageDidShow handling to
null-check the returned CTInboxMessage from getInboxMessageForId(...) and if
it's null either return early (skip analytics) or fall back to using the
original inboxMessage for analytics, and add a small debug log mentioning the
missing messageId; reference CTInboxMessage, getInboxMessageForId(...),
inboxMessage, and messageDidShow when locating the fix.

In
`@clevertap-core/src/main/java/com/clevertap/android/sdk/network/fetch/InboxDeleteCall.kt`:
- Around line 53-61: The current when-block in InboxDeleteCall treats every
non-200 response as CallResult.Disabled which is incorrect; update the response
handling in InboxDeleteCall (the method processing the HTTP response) to return
CallResult.Success(Unit) for 200, return CallResult.Disabled only for the
explicit disable status (e.g., 403), and for all other non-200 statuses return a
CallResult.HttpError containing the response code (and optional body/message)
instead of flipping to Disabled; keep logger calls but log different messages
per branch (200, 403, other) so transient 5xx/429 responses are surfaced as
errors rather than disabling the V2 inbox for the session.
- Around line 45-47: The current execute() implementation in InboxDeleteCall
wraps work with withContext(dispatcher) and uses catch (e: Exception) which
swallows CancellationException; update the exception handling so
CancellationException is re-thrown and not converted to
CallResult.NetworkFailure. Concretely, in the execute() method surrounding
withContext(dispatcher) change the single catch to first detect/rethrow
CancellationException (either via a specific catch (e: CancellationException) {
throw e } or by checking if (e is CancellationException) throw e) and only then
return CallResult.NetworkFailure for other Exceptions, making the same change
for both catch sites that currently return CallResult.NetworkFailure.

In
`@clevertap-core/src/main/java/com/clevertap/android/sdk/network/fetch/InboxFetchCall.kt`:
- Around line 60-70: The current when(response.code) branch treats every non-200
response as CallResult.Disabled which incorrectly disables Inbox V2 on
transient/server errors; change the logic in InboxFetchCall.kt (the
response.code handling) to only return CallResult.Disabled for the explicit
disable status (403) and for all other non-200 codes return a
CallResult.HttpError (include the HTTP status and response body or message) so
failures remain observable; ensure you still read the body safely (like
response.readBody() ?: "") when constructing the HttpError to include useful
context.
- Around line 52-54: The catch blocks currently catch Exception (in the
withContext scope and the later block) which swallows CancellationException;
update each catch to rethrow CancellationException immediately (e.g., if (e is
CancellationException) throw e) and only convert other exceptions into
CallResult.NetworkFailure(e) so coroutine cancellation propagates correctly;
adjust the catch around withContext and the later catch (e: Exception) that
returns CallResult.NetworkFailure to follow this pattern, keeping references to
CallResult.NetworkFailure and the withContext scope.

In
`@clevertap-core/src/main/java/com/clevertap/android/sdk/response/InboxV2Response.kt`:
- Around line 78-80: The verbose log prints the raw messages JSON (messages)
which can leak inbox content; update the logger call in InboxV2Response (around
the logger.verbose lines and before _processInboxMessages) to avoid logging full
payloads — log only safe metadata such as messages.length(), source, and
optionally a list of message IDs or counts per type, and remove or redact the
"$messages" interpolation so the raw JSON is never written to logs.

In
`@clevertap-core/src/test/java/com/clevertap/android/sdk/ActivityLifeCycleManagerTest.kt`:
- Around line 167-175: The test currently sets
coreState.coreMetaData.isAppLaunchPushed = true so both
activityLifeCycleManager.activityResumed(mockActivity) calls are suppressed and
the "submit once then suppress" path isn't exercised; change the setup to start
with isAppLaunchPushed = false (or remove that assignment), call
activityLifeCycleManager.activityResumed(mockActivity) twice, and then assert
inboxV2Bridge.submit was invoked exactly once to verify the first call triggers
submit and the second is suppressed; references:
coreState.coreMetaData.isAppLaunchPushed,
activityLifeCycleManager.activityResumed(...), and inboxV2Bridge.submit(...).

In
`@clevertap-core/src/test/java/com/clevertap/android/sdk/AnalyticsManagerTest.kt`:
- Around line 40-43: Tests fail to compile due to ambiguous assertions: remove
the duplicate imports from kotlin.test so only org.junit.Assert versions are
imported; specifically delete any imports of assertEquals and assertFalse from
kotlin.test (leave import lines for org.junit.Assert.assertEquals, assertFalse,
assertNotNull, assertTrue intact) so calls in AnalyticsManagerTest.kt resolve
unambiguously.

In
`@clevertap-core/src/test/java/com/clevertap/android/sdk/db/dao/InboxMessageDAOImplTest.kt`:
- Around line 392-404: The test currently uses Long.MAX_VALUE which lets
PENDING_INDEXING rows pass the staleness cutoff; change the test to prove
INDEXED status drives inclusion by (a) inserting two V2 messages for the same
user via inboxMessageDAO.upsertMessages using getCtMsgDao(..., source =
InboxMessageSource.V2) — one left as PENDING_INDEXING and another marked INDEXED
via inboxMessageDAO.markIndexed(...) — and (b) call
inboxMessageDAO.findSweepableV2Ids(userId, a cutoff that excludes the
PENDING_INDEXING row but includes the INDEXED row) and assert the result
contains only the ID you marked INDEXED. This ensures findSweepableV2Ids is
validated for INDEXED vs PENDING_INDEXING behavior.

In `@clevertap-core/src/test/java/com/clevertap/android/sdk/db/DBAdapterTest.kt`:
- Around line 321-334: The test currently uses Long.MAX_VALUE as the cutoff so a
PENDING_INDEXING row (date=100L) is sweepable regardless of markIndexed; change
the assertion to use a cutoff that would NOT make the original pending row
sweepable unless markIndexed changed its state—e.g. call
dbAdapter.findSweepableV2Ids(userId, 99L) or another value < 100L—and assert
that the returned list contains msgId after calling
dbAdapter.markIndexed(listOf(msgId), userId); reference the test helpers/getter
getV2MsgDao, the InboxIndexState.PENDING_INDEXING initial state, and the methods
markIndexed and findSweepableV2Ids when applying this change.

In
`@clevertap-core/src/test/java/com/clevertap/android/sdk/network/fetch/InboxFetchCallTest.kt`:
- Around line 147-154: In the test `null header from builder returns
NetworkFailure without hitting network` after calling `newCall(http, header =
null).execute()` add an assertion that the provided MockHttpClient recorded zero
requests to ensure the short-circuit prevented any network activity; locate the
MockHttpClient instance (variable `http`) and use its request-count or
equivalent inspection API (e.g., verify zero calls, no lastRequest, or
requestCount == 0) to assert no HTTP request was executed in addition to the
existing NetworkFailure assertion.

In `@docs/EXAMPLES.md`:
- Around line 349-350: Update the docs to clarify fetchInbox callback semantics:
change the sentence around "success is true if the fetch completed and new
messages were received" to state that success indicates the fetch completed
successfully (regardless of whether new messages arrived) and that empty results
are valid; note that inbox listener callbacks (inboxMessagesDidUpdate) will
still fire automatically when new messages are present. Reference the fetchInbox
callback and inboxMessagesDidUpdate listener so integrators understand success
means completion, not necessarily new-message arrival.

In `@sample/src/main/java/com/clevertap/demo/ui/main/HomeScreenViewModel.kt`:
- Around line 393-397: setProfileLocation() is currently a no-op because it
reassigns cleverTapAPI.location to itself; replace that with assigning an actual
location value (e.g., a real Location object or a stored/current location
variable) to cleverTapAPI?.location and ensure you handle nullability before
calling printVar. Specifically, update the method so cleverTapAPI?.location =
<actualLocation> (for example a currentLocation or profileLocation variable or a
new Location(lat, lon)), then call printVar("Location",
cleverTapAPI?.location?.toString() ?: "null") so the code sets a real profile
location and avoids NPEs when printing.

---

Outside diff comments:
In `@clevertap-core/src/main/java/com/clevertap/android/sdk/db/CtDatabase.kt`:
- Around line 67-83: The migration for oldVersion == 1 recreates inboxMessages
via CREATE_INBOX_MESSAGES_TABLE but later runs ALTER TABLE ADD COLUMN for
"source" and "index_state", causing duplicate-column errors; update
CtDatabase.kt to check whether those columns already exist before running the
ALTERs (e.g. query PRAGMA table_info('inboxMessages') or similar helper) and
only call executeStatement to add columns if they are absent; apply the same
guard where the same ALTERs occur (the blocks referencing
CREATE_INBOX_MESSAGES_TABLE, CREATE_INBOX_MESSAGES_TABLE-related ALTERs and the
code areas around the other occurrences noted) so the v1→v7 path skips duplicate
ADD COLUMN statements.

In
`@clevertap-core/src/main/java/com/clevertap/android/sdk/response/DisplayUnitResponse.java`:
- Around line 85-89: The handler in DisplayUnitResponse currently returns early
when messages is empty, leaving stale data; instead, detect messages == null
versus messages.length()==0 and for the empty-array case call
cache.updateDisplayUnits(...) with an empty list (or equivalent clear), invoke
the display-units callback/notification path just as with a populated payload,
and log the empty payload event via logger.verbose; keep the null check
returning early but ensure messages.length()==0 triggers cache clearing and
callback invocation so stale units are removed.

---

Nitpick comments:
In
`@clevertap-core/src/main/java/com/clevertap/android/sdk/db/dao/InboxPendingActionsDAO.kt`:
- Around line 167-174: The current insert in InboxPendingActionsDAO uses
dbHelper.writableDatabase.insertWithOnConflict(...,
SQLiteDatabase.CONFLICT_IGNORE) and treats any -1 result as failure; change the
success check to treat -1 (constraint-ignored duplicate) as success for
idempotent semantics: capture the insertWithOnConflict return into a variable
(e.g., result) and return true if result >= 0 OR result == -1; keep the
SQLiteException catch/log using logger.verbose for Table.INBOX_PENDING_DELETES
to preserve error handling.
- Around line 193-200: The addPendingRead method currently treats insert result
as successful with ">= 0"—make it consistent with the idempotent semantics
applied to addPendingDelete by changing the success check to use "> 0" instead;
update the return expression in the insert block that references
Table.INBOX_PENDING_READS.tableName so the method returns true only for a
positive rowId while preserving the existing SQLiteException catch and logging.

In
`@clevertap-core/src/main/java/com/clevertap/android/sdk/inbox/CTInboxController.java`:
- Around line 601-605: The negative-TTL branch in resolvePendingActionExpiry
(method) is unclear: add a concise comment above the ternary that explains why
dao.getExpires() might be negative (e.g., legacy/formatting/parsing errors or
sentinel values) and that in such cases we intentionally apply
PENDING_DELETE_DEFAULT_TTL_SECONDS to avoid immediate expiry; reference
CTMessageDAO.getExpires() and the PENDING_DELETE_DEFAULT_TTL_SECONDS constant in
the comment so future readers understand the fallback semantics.
- Around line 141-171: Partitioning V2 messages currently happens under
messagesLock then releases it before writing pendingRows and calling
_deleteMessagesForIds, allowing a TOCTOU; to fix, perform the V2 partitioning,
pendingRows construction (resolvePendingActionExpiry), the
dbAdapter.addPendingDeletes(...) call, and the _deleteMessagesForIds(messageIDs)
invocation while holding the same higher-level inbox controller lock
(ctLockManager.getInboxControllerLock()) so the sequence (v2Messages/pendingRows
creation -> db write -> deletion ->
callbackManager._notifyInboxMessagesDidUpdate()) is atomic; adjust
synchronization so messagesLock work happens inside that controller lock or
acquire controller lock first, then iterate messages to build
v2Messages/pendingRows, call dbAdapter.addPendingDeletes, call
_deleteMessagesForIds, and finally call inboxDeleteCoordinator.syncDelete if
needed.

In
`@clevertap-core/src/main/java/com/clevertap/android/sdk/inbox/EventSuppressor.kt`:
- Around line 24-30: The ConcurrentHashMap lastSeen used by shouldSuppress can
grow unbounded for unbounded key spaces; update the implementation to prevent
memory leak by adding eviction: either replace lastSeen with a bounded cache
with TTL (e.g., use a ConcurrentLinkedHashMap/Guava Cache or an LRU with
maximumSize and expireAfterWrite using the same windowMs) or implement periodic
cleanup of entries older than windowMs when calling shouldSuppress; ensure
symbols referenced are lastSeen, shouldSuppress, windowMs and preserve
thread-safety for concurrent access.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 5d408f2a-68af-4e34-99e7-1561ac95af2e

📥 Commits

Reviewing files that changed from the base of the PR and between 35eabb1 and e3090b2.

📒 Files selected for processing (86)

• CHANGELOG.md
• README.md
• clevertap-core/build.gradle
• clevertap-core/src/androidTest/kotlin/PIFlushWorkInstrumentationTest.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/ActivityLifeCycleManager.java
• clevertap-core/src/main/java/com/clevertap/android/sdk/AnalyticsManager.java
• clevertap-core/src/main/java/com/clevertap/android/sdk/BaseAnalyticsManager.java
• clevertap-core/src/main/java/com/clevertap/android/sdk/CleverTapAPI.java
• clevertap-core/src/main/java/com/clevertap/android/sdk/CleverTapFactory.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/Constants.java
• clevertap-core/src/main/java/com/clevertap/android/sdk/ControllerManager.java
• clevertap-core/src/main/java/com/clevertap/android/sdk/CoreState.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/FetchInboxCallback.java
• clevertap-core/src/main/java/com/clevertap/android/sdk/db/CtDatabase.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/db/DBAdapter.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/db/dao/InboxMessageDAO.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/db/dao/InboxMessageDAOImpl.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/db/dao/InboxPendingActionsDAO.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/displayunits/CTDisplayUnitController.java
• clevertap-core/src/main/java/com/clevertap/android/sdk/displayunits/DisplayUnitCache.java
• clevertap-core/src/main/java/com/clevertap/android/sdk/inbox/CTInboxController.java
• clevertap-core/src/main/java/com/clevertap/android/sdk/inbox/CTInboxListViewFragment.java
• clevertap-core/src/main/java/com/clevertap/android/sdk/inbox/CTMessageDAO.java
• clevertap-core/src/main/java/com/clevertap/android/sdk/inbox/EventSuppressor.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/inbox/InboxDeleteCoordinator.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/inbox/InboxIndexState.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/inbox/InboxMessageSource.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/inbox/InboxV2Bridge.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/inbox/InboxV2Fetcher.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/inbox/InboxV2Merger.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/login/LoginController.java
• clevertap-core/src/main/java/com/clevertap/android/sdk/network/api/CtApi.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/network/fetch/CallResult.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/network/fetch/EndpointCall.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/network/fetch/EventRequestBody.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/network/fetch/FetchThrottle.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/network/fetch/FetchTrigger.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/network/fetch/InboxDeleteCall.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/network/fetch/InboxFetchCall.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/network/fetch/InboxV2EventBuilder.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/network/fetch/NetworkScope.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/response/DisplayUnitResponse.java
• clevertap-core/src/main/java/com/clevertap/android/sdk/response/InboxV2DeliverySource.kt
• clevertap-core/src/main/java/com/clevertap/android/sdk/response/InboxV2Response.kt
• clevertap-core/src/main/res/layout/inbox_list_view.xml
• clevertap-core/src/test/java/com/clevertap/android/sdk/ActivityLifeCycleManagerTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/AnalyticsManagerTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/CleverTapAPITest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/ConstantsTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/MockAnalyticsManager.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/MockCoreState.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/db/DBAdapterTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/db/DatabaseHelperMigrationTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/db/dao/InboxMessageDAOImplTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/db/dao/InboxPendingActionsDAOImplTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/displayunits/CTDisplayUnitControllerTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/inbox/CTInboxControllerTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/inbox/CTMessageDAOTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/inbox/EventSuppressorTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/inbox/InboxDeleteCoordinatorTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/inbox/InboxV2BridgeTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/inbox/InboxV2FetcherTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/inbox/InboxV2MergerTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/login/LoginControllerTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/network/api/CtApiInboxFetchTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/network/fetch/CallResultTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/network/fetch/EventRequestBodyTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/network/fetch/FetchThrottleTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/network/fetch/InboxDeleteCallTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/network/fetch/InboxFetchCallTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/network/fetch/InboxV2EventBuilderTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/network/fetch/NetworkScopeTest.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/network/http/MockHttpClient.kt
• clevertap-core/src/test/java/com/clevertap/android/sdk/response/InboxV2ResponseTest.kt
• clevertap-pushtemplates/src/main/java/com/clevertap/android/pushtemplates/content/VerticalImageBigContentView.kt
• docs/CTCORECHANGELOG.md
• docs/CTGEOFENCE.md
• docs/CTPUSHTEMPLATES.md
• docs/EXAMPLES.md
• gradle-scripts/jacoco_root.gradle
• gradle/libs.versions.toml
• sample/build.gradle
• sample/src/main/java/com/clevertap/demo/ui/main/HomeScreenModel.kt
• sample/src/main/java/com/clevertap/demo/ui/main/HomeScreenViewModel.kt
• templates/CTCORECHANGELOG.md
• templates/EXAMPLES.md

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

fd -t f "InboxDeleteCall.kt"

Repository: CleverTap/clevertap-android-sdk

Length of output: 163

---

🏁 Script executed:

wc -l clevertap-core/src/main/java/com/clevertap/android/sdk/network/fetch/InboxDeleteCall.kt

Repository: CleverTap/clevertap-android-sdk

Length of output: 166

---

🏁 Script executed:

cat -n clevertap-core/src/main/java/com/clevertap/android/sdk/network/fetch/InboxDeleteCall.kt

Repository: CleverTap/clevertap-android-sdk

Length of output: 4170

---

🏁 Script executed:

# Check for CancellationException imports and usage patterns in the codebase
rg "CancellationException" --type kotlin -B 3 -A 3

Repository: CleverTap/clevertap-android-sdk

Length of output: 6671

---

🏁 Script executed:

# Check what Exception types are caught in similar coroutine patterns
rg "catch\s*\(\s*e:\s*Exception\s*\)" --type kotlin -B 2 -A 2 | head -60

Repository: CleverTap/clevertap-android-sdk

Length of output: 6607

---

Replace catch (e: Exception) with explicit CancellationException re-throw on lines 45–47 and 64–67.

The execute() method wraps code in withContext(dispatcher) but catches Exception, which also catches CancellationException. This swallows the cancellation signal and converts it to NetworkFailure, breaking the coroutine cancellation contract. The interface EndpointCall<T> and CallResult explicitly document: "don't swallow CancellationException."

Suggested fix

+import kotlinx.coroutines.CancellationException
@@
-        } catch (e: Exception) {
+        } catch (e: CancellationException) {
+            throw e
+        } catch (e: Exception) {
             return@withContext CallResult.NetworkFailure(e)
         }
@@
-        } catch (e: Exception) {
+        } catch (e: CancellationException) {
+            throw e
+        } catch (e: Exception) {
             logger.verbose("InboxV2", "delete failed: $e")
             CallResult.NetworkFailure(e)
         }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@clevertap-core/src/main/java/com/clevertap/android/sdk/network/fetch/InboxDeleteCall.kt`
around lines 45 - 47, The current execute() implementation in InboxDeleteCall
wraps work with withContext(dispatcher) and uses catch (e: Exception) which
swallows CancellationException; update the exception handling so
CancellationException is re-thrown and not converted to
CallResult.NetworkFailure. Concretely, in the execute() method surrounding
withContext(dispatcher) change the single catch to first detect/rethrow
CancellationException (either via a specific catch (e: CancellationException) {
throw e } or by checking if (e is CancellationException) throw e) and only then
return CallResult.NetworkFailure for other Exceptions, making the same change
for both catch sites that currently return CallResult.NetworkFailure.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

find . -name "InboxFetchCall.kt" -type f

Repository: CleverTap/clevertap-android-sdk

Length of output: 164

---

🏁 Script executed:

cat -n clevertap-core/src/main/java/com/clevertap/android/sdk/network/fetch/InboxFetchCall.kt

Repository: CleverTap/clevertap-android-sdk

Length of output: 3909

---

Preserve coroutine cancellation instead of catching it as a generic failure.

Lines 52-54 and 73-76 catch Exception, which includes CancellationException. When a coroutine is cancelled, swallowing the CancellationException prevents proper cancellation propagation and can cause resource leaks or unexpected behavior. Cancellation should be rethrown separately.

Suggested fix

+import kotlinx.coroutines.CancellationException
@@
-        } catch (e: Exception) {
+        } catch (e: CancellationException) {
+            throw e
+        } catch (e: Exception) {
             return@withContext CallResult.NetworkFailure(e)
         }
@@
-        } catch (e: Exception) {
+        } catch (e: CancellationException) {
+            throw e
+        } catch (e: Exception) {
             logger.verbose("InboxV2", "fetch failed: $e")
             CallResult.NetworkFailure(e)
         }

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	} catch (e: Exception) {
	return@withContext CallResult.NetworkFailure(e)
	}
	} catch (e: CancellationException) {
	throw e
	} catch (e: Exception) {
	return@withContext CallResult.NetworkFailure(e)
	}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@clevertap-core/src/main/java/com/clevertap/android/sdk/network/fetch/InboxFetchCall.kt`
around lines 52 - 54, The catch blocks currently catch Exception (in the
withContext scope and the later block) which swallows CancellationException;
update each catch to rethrow CancellationException immediately (e.g., if (e is
CancellationException) throw e) and only convert other exceptions into
CallResult.NetworkFailure(e) so coroutine cancellation propagates correctly;
adjust the catch around withContext and the later catch (e: Exception) that
returns CallResult.NetworkFailure to follow this pattern, keeping references to
CallResult.NetworkFailure and the withContext scope.