Skip to content

Conversation

@runningcode
Copy link
Contributor

@runningcode runningcode commented Oct 15, 2025

Summary

Refactors the async checkForUpdate() API to return a Future<UpdateStatus> instead of using a callback pattern, and uses SentryExecutorService for background execution instead of spawning new threads.

Changes

  • API Change: Replaced callback-based checkForUpdate(UpdateCallback) with Future-based checkForUpdate()
  • Thread Management: Now uses SentryExecutorService instead of creating new threads for each call
  • Simplified API: Removed UpdateCallback interface entirely
  • Consistency: Aligns with existing SDK patterns for async operations
  • Resource Management: Leverages the shared thread pool to avoid creating unbounded threads

Benefits

  • More flexible API - callers control which thread to consume the result on
  • Better resource management through thread pooling
  • Cleaner API surface without callback confusion
  • Consistent with other SDK components that use SentryExecutorService

#skip-changelog

Fixes EME-413

🤖 Generated with Claude Code

@linear
Copy link

linear bot commented Oct 15, 2025

@github-actions
Copy link
Contributor

github-actions bot commented Oct 15, 2025

Messages
📖 Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against f571681

@runningcode runningcode requested a review from chromy October 15, 2025 14:50
onResult.onResult(result)
Thread {
val result = checkForUpdateBlocking()
onResult.onResult(result)

Choose a reason for hiding this comment

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

Potential bug: The onResult callback is not wrapped in a try-catch block, which could lead to an app crash if the user's implementation throws an exception.
  • Description: The onResult.onResult(result) call is executed on a background thread without any exception handling. If the user-provided onResult callback throws an exception, it will be uncaught on that thread, likely causing the entire application to crash. This is inconsistent with other parts of the SDK, such as the handling of OnDiscardCallback, where user-provided callbacks are defensively wrapped in a try-catch block to prevent such failures.

  • Suggested fix: Wrap the onResult.onResult(result) call within a try-catch (Throwable e) block. Log any caught exceptions using the provided logger, similar to the pattern used for other user callbacks in the SDK to protect the app from crashing.
    severity: 0.75, confidence: 0.95

Did we get this right? 👍 / 👎 to inform future reviews.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is a good point but we should just crash here.

@github-actions
Copy link
Contributor

github-actions bot commented Oct 15, 2025

Performance metrics 🚀

  Plain With Sentry Diff
Startup time 314.08 ms 392.64 ms 78.56 ms
Size 1.58 MiB 2.12 MiB 549.37 KiB

Baseline results on branch: main

Startup times

Revision Plain With Sentry Diff
b3d8889 420.46 ms 453.71 ms 33.26 ms
ee747ae 386.94 ms 431.43 ms 44.49 ms
ee747ae 400.46 ms 423.61 ms 23.15 ms
9fbb112 361.43 ms 427.57 ms 66.14 ms
cf708bd 408.35 ms 458.98 ms 50.63 ms
ee747ae 396.82 ms 441.67 ms 44.86 ms
cf708bd 434.73 ms 502.96 ms 68.22 ms
bdbe1f4 380.66 ms 464.44 ms 83.78 ms
806307f 357.85 ms 424.64 ms 66.79 ms
f634d01 375.06 ms 420.04 ms 44.98 ms

App size

Revision Plain With Sentry Diff
b3d8889 1.58 MiB 2.10 MiB 535.07 KiB
ee747ae 1.58 MiB 2.10 MiB 530.95 KiB
ee747ae 1.58 MiB 2.10 MiB 530.95 KiB
9fbb112 1.58 MiB 2.11 MiB 539.18 KiB
cf708bd 1.58 MiB 2.11 MiB 539.71 KiB
ee747ae 1.58 MiB 2.10 MiB 530.95 KiB
cf708bd 1.58 MiB 2.11 MiB 539.71 KiB
bdbe1f4 1.58 MiB 2.11 MiB 538.88 KiB
806307f 1.58 MiB 2.10 MiB 533.42 KiB
f634d01 1.58 MiB 2.10 MiB 533.40 KiB

Previous results on branch: no/eme-413-async-update-check

Startup times

Revision Plain With Sentry Diff
2e1e2d9 421.18 ms 549.46 ms 128.27 ms
e8a6a9c 317.06 ms 373.48 ms 56.42 ms
9ac0631 402.78 ms 476.65 ms 73.87 ms
15641a2 394.08 ms 431.73 ms 37.65 ms
1f983f6 324.46 ms 452.26 ms 127.80 ms
b9cb481 381.29 ms 429.46 ms 48.17 ms
9212043 373.06 ms 450.63 ms 77.57 ms
3b25d11 278.36 ms 350.40 ms 72.03 ms
b15d8fa 351.88 ms 417.20 ms 65.32 ms

App size

Revision Plain With Sentry Diff
2e1e2d9 1.58 MiB 2.11 MiB 539.76 KiB
e8a6a9c 1.58 MiB 2.12 MiB 548.12 KiB
9ac0631 1.58 MiB 2.11 MiB 539.70 KiB
15641a2 1.58 MiB 2.11 MiB 539.76 KiB
1f983f6 1.58 MiB 2.11 MiB 539.76 KiB
b9cb481 1.58 MiB 2.11 MiB 539.76 KiB
9212043 1.58 MiB 2.11 MiB 539.71 KiB
3b25d11 1.58 MiB 2.12 MiB 548.53 KiB
b15d8fa 1.58 MiB 2.11 MiB 539.70 KiB

// TODO implement this in a async way
val result = checkForUpdateBlocking()
onResult.onResult(result)
public override fun checkForUpdate(): java.util.concurrent.Future<UpdateStatus> {
Copy link
Member

Choose a reason for hiding this comment

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

also, I guess as a nice follow-up we could have distribution-ktx that converts this to coroutines, but that's definitely not something we need to do now, if ever :)

Copy link
Member

@romtsn romtsn left a comment

Choose a reason for hiding this comment

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

LGTM, thanks for using the executor service!

cursor[bot]

This comment was marked as outdated.

runningcode and others added 8 commits October 20, 2025 16:04
…EME-413)

Implement async version of checkForUpdate that runs on a background thread
instead of blocking the calling thread. The callback is invoked on the
background thread, allowing callers to dispatch to main thread if needed.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
…ync checkForUpdate (EME-413)

Replace callback-based API with Future-based API to avoid confusion and improve consistency with SDK patterns. Use SentryExecutorService instead of spawning new threads to better manage resources.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
…y (EME-413)

Replace CompletableFuture.completedFuture() with a custom CompletedFuture
implementation in NoOpDistributionApi to maintain Android API 21+ compatibility.
CompletableFuture was only added in Android API 24.

The new CompletedFuture follows the same pattern as existing CancelledFuture
implementations in the codebase and returns an immediately completed Future
with a result.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
…EME-413)

Add explicit import for java.util.concurrent.Future and use short form
instead of fully qualified name in method signature.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
…API (EME-413)

Update sample app to use the new Future-based checkForUpdate() method
instead of the old callback-based API. The Future is processed on a
background thread and results are posted back to the UI thread.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
Improves code readability by importing Future instead of using fully qualified name.
Adds guidance comment suggesting developers convert the sample to their preferred
async library (RxJava, Coroutines, etc.) in production code.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
Applied spotlessApply formatting to wrap long comment line.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
@runningcode runningcode force-pushed the no/eme-413-async-update-check branch from 7997cac to 9b430e8 Compare October 20, 2025 14:06
@runningcode runningcode enabled auto-merge (squash) October 21, 2025 13:12
Copy link
Contributor

@chromy chromy left a comment

Choose a reason for hiding this comment

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

lgtm, not in love with the new Thread in the sample still but we can always revisit that later once the actual code is in

@runningcode runningcode merged commit d5a29b6 into main Oct 21, 2025
59 of 60 checks passed
@runningcode runningcode deleted the no/eme-413-async-update-check branch October 21, 2025 14:09
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.

5 participants