[CloudWatch] Logging worker cancellation spam with ExistingWorkPolicy.REPLACE

[NicolasBrandi]

Before opening, please confirm:

• I have searched for duplicate or closed issues and discussions.

Language and Async Model

Kotlin

Amplify Categories

Not applicable

Gradle script dependencies

Details

// Put output below this line

Environment information

Details

# Put output below this line

Please include any relevant guides or documentation you're referencing

No response

Describe the feature request

I am seeing frequent WorkManager cancellation warnings from the CloudWatch logging plugin. The stack shows cancellations of CloudwatchRouterWorker/CloudwatchLogsSyncWorker caused by CancelWorkRunnable.forNameInline, which aligns with enqueueSync() using ExistingWorkPolicy.REPLACE.

amplify-android/aws-logging-cloudwatch/src/main/java/com/amplifyframework/logging/cloudwatch/CloudWatchLogManager.kt

Line 255 in 0d87830

ExistingWorkPolicy.REPLACE,

Example log of the cancelation:

Work [ id=..., tags={ CloudwatchRouterWorker, CloudwatchLogsSyncWorker } ] was cancelled
WorkerStoppedException
… CancelWorkRunnable.forNameInline …

Is there a recommended way to avoid the cancellation spam? Would you consider using a different policy (e.g., KEEP or self‑rescheduling) or suppressing cancellation warnings?

Initialization steps (if applicable)

No response

Code Snippet

// Put your code below this line.

Configuration File

No response

GraphQL Schema

Details

// Put your schema below this line

Additional information and screenshots

No response

[mattcreaser]

Thanks for opening this detailed issue @NicolasBrandi. We're going to have to take a look at why REPLACE was chosen as the default policy to see what's the best approach here. We'll investigate and get back to you.

[jvh-aws]

The cancellation warnings don't indicate log loss. The worker reschedules itself in a finally block (CloudwatchLogsSyncWorker.kt:38) using ExistingWorkPolicy.REPLACE (CloudWatchLogManager.kt:255), which cancels any pending worker before scheduling the next one. This creates logcat spam but logs are uploaded correctly since they're persisted and only deleted after successful upload (CloudWatchLogManager.kt:141). The isSyncInProgress flag (CloudWatchLogManager.kt:107-109) prevents concurrent syncs from corrupting data.

We will further investigate approaches to remove the mentioned logcat logs or using ExistingWorkPolicy.KEEP instead of ExistingWorkPolicy.REPLACE.