Skip to content

fix: [SDK-4995] always run suspendifyWithCompletion onComplete - #2764

Open
fadi-george wants to merge 1 commit into
mainfrom
fadi/sdk-4995-completion-callback
Open

fadi-george wants to merge 1 commit into
mainfrom
fadi/sdk-4995-completion-callback

Conversation

@fadi-george

Copy link
Copy Markdown
Contributor

Description

One Line Summary

suspendifyWithCompletion always runs onComplete, including when the block throws or the job is cancelled before it starts.

Details

Motivation

Split out of #2712. Callers that release a resource in onComplete (for example a PendingResult.finish()) could leak it when the block threw, because onComplete only ran on success.

Scope

  • onComplete is registered with invokeOnCompletion, so it runs on success, failure, and pre-start cancellation.
  • Exceptions thrown by onComplete are logged instead of escaping.
  • No production caller passes onComplete today, so there is no behavior change for existing SDK paths.

Testing

Unit testing

Added a test that onComplete runs when the block throws.

Manual testing

Not tested on device; this is a threading helper with no production caller of the changed parameter.

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

Co-authored-by: Cursor <cursoragent@cursor.com>
@fadi-george
fadi-george requested a review from a team as a code owner September 23, 2026 21:17
@github-actions

Copy link
Copy Markdown
Contributor

📊 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

  • ThreadUtils.kt: 8/9 touched executable lines (88.9%) (12 touched lines in diff)

Overall (aggregate gate)

8/9 touched executable lines covered (88.9% — requires ≥ 80%)

📥 View workflow run

@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.

Two nits.

}
}
// invokeOnCompletion also fires when the job is cancelled before its body starts.
job.invokeOnCompletion {

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.

invokeOnCompletion runs on the completing thread, or inline on the caller if the job is already finished. suspendifyOnIO's KDoc still says onComplete runs on the background thread.

},
)

latch.await()

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.

latch.await() has no timeout, so a regression hangs the suite. This also does not cover cancel-before-start, which is the case the change is for.

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