Handled / catched exceptions are getting into Azure Application Insights

[chhauss-a]

Expected behavior

We have a handled exception in our application. When that exception is thrown and catched we should not see the occurrence of that exception in Application Insights.

Actual behavior

The thrown and catched exception is displayed in our Application Insights.

To Reproduce

1. Create a new Spring Boot application with a scheduled task and use ShedLock to synchronize that task over multiple containers running in parallel with mongoDB setup (cosmos db)

// Run every 15 minutes (xx:00, xx:15, xx:30, xx:45)
@Scheduled(cron = "0 */15 * * * *")
@SchedulerLock(name = "uniqueString", lockAtMostFor = "14m", lockAtLeastFor = "14m")
public void myScheduledTask() {
    service.runTask();
}

2. Setup the MongoLockProvider for ShedLock

@Bean
public LockProvider lockProvider(final MongoClient mongo) {
    return new MongoLockProvider(mongo.getDatabase(mongoDatabaseName));
}

3. Setup Application Insights for the Spring Boot application
4. Run the application with 2 containers in parallel (in our case in a container app)
5. Observe the Application Insights Exceptions: Every time the task is scheduled ShedLock will try to lock the task in both containers. That means every time one of the containers will receive an duplicate key exception that is catched within the MongoLockProvider. These exceptions are shown in Application Insights.

System information

Please provide the following information:

• SDK Version: Java SDK 21-temurin
• OS type and version: eclipse-temurin:21-jre-alpine docker image
• Application Server type and version (if applicable): Azure Container App
• Using spring-boot? Yes with Spring-Boot-Starter-Parent v3.3.2
• Additional relevant libraries (with version, if applicable): ShedLock v5.14.0 => net.javacrumbs.shedlock -> shedlock-spring & shedlock-provider-mongo

[heyams]

@chhauss-a can you share the stack trace where the exception is being thrown and where it's caught?

[chhauss-a]

Hey @heyams , thanks for looking into this issue!

The exception that is thrown is the following:

com.mongodb.MongoCommandException: Command failed with error 11000 (DuplicateKey): 'E11000 duplicate key error collection: <our-collection>.shedLock. Failed _id or unique index constraint.' on server <our-server>. The full response is {"ok": 0.0, "errmsg": "E11000 duplicate key error collection: <our-collection>.shedLock. Failed _id or unique index constraint.", "code": 11000, "codeName": "DuplicateKey"}
	at com.mongodb.internal.connection.ProtocolHelper.getCommandFailureException(ProtocolHelper.java:205)
	at com.mongodb.internal.connection.InternalStreamConnection.receiveCommandMessageResponse(InternalStreamConnection.java:454)
	at com.mongodb.internal.connection.InternalStreamConnection.sendAndReceive(InternalStreamConnection.java:372)
	at com.mongodb.internal.connection.UsageTrackingInternalConnection.sendAndReceive(UsageTrackingInternalConnection.java:114)
	at com.mongodb.internal.connection.DefaultConnectionPool$PooledConnection.sendAndReceive(DefaultConnectionPool.java:765)
	at com.mongodb.internal.connection.CommandProtocolImpl.execute(CommandProtocolImpl.java:76)
	at com.mongodb.internal.connection.DefaultServer$DefaultServerProtocolExecutor.execute(DefaultServer.java:209)
	at com.mongodb.internal.connection.DefaultServerConnection.executeProtocol(DefaultServerConnection.java:115)
	at com.mongodb.internal.connection.DefaultServerConnection.command(DefaultServerConnection.java:83)
	at com.mongodb.internal.connection.DefaultServerConnection.command(DefaultServerConnection.java:74)
	at com.mongodb.internal.connection.DefaultServer$OperationCountTrackingConnection.command(DefaultServer.java:299)
	at com.mongodb.internal.operation.SyncOperationHelper.lambda$executeRetryableWrite$9(SyncOperationHelper.java:243)
	at com.mongodb.internal.operation.SyncOperationHelper.lambda$withSourceAndConnection$0(SyncOperationHelper.java:127)
	at com.mongodb.internal.operation.SyncOperationHelper.withSuppliedResource(SyncOperationHelper.java:152)
	at com.mongodb.internal.operation.SyncOperationHelper.lambda$withSourceAndConnection$1(SyncOperationHelper.java:126)
	at com.mongodb.internal.operation.SyncOperationHelper.withSuppliedResource(SyncOperationHelper.java:152)
	at com.mongodb.internal.operation.SyncOperationHelper.withSourceAndConnection(SyncOperationHelper.java:125)
	at com.mongodb.internal.operation.SyncOperationHelper.lambda$executeRetryableWrite$10(SyncOperationHelper.java:229)
	at com.mongodb.internal.operation.SyncOperationHelper.lambda$decorateWriteWithRetries$11(SyncOperationHelper.java:283)
	at com.mongodb.internal.async.function.RetryingSyncSupplier.get(RetryingSyncSupplier.java:67)
	at com.mongodb.internal.operation.SyncOperationHelper.executeRetryableWrite(SyncOperationHelper.java:255)
	at com.mongodb.internal.operation.BaseFindAndModifyOperation.execute(BaseFindAndModifyOperation.java:79)
	at com.mongodb.client.internal.MongoClientDelegate$DelegateOperationExecutor.execute(MongoClientDelegate.java:173)
	at com.mongodb.client.internal.MongoCollectionImpl.executeFindOneAndUpdate(MongoCollectionImpl.java:761)
	at com.mongodb.client.internal.MongoCollectionImpl.findOneAndUpdate(MongoCollectionImpl.java:741)
	at net.javacrumbs.shedlock.provider.mongo.MongoLockProvider.lock(MongoLockProvider.java:107)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
	at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:354)
	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:216)
	at jdk.proxy3/jdk.proxy3.$Proxy169.lock(Unknown Source)
	at net.javacrumbs.shedlock.core.DefaultLockingTaskExecutor.executeWithLock(DefaultLockingTaskExecutor.java:63)
	at net.javacrumbs.shedlock.spring.aop.MethodProxyScheduledLockAdvisor$LockingInterceptor.invoke(MethodProxyScheduledLockAdvisor.java:79)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184)
	at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:768)
	at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:720)
	at <our-package-name>.<our-scheduling-class>$$SpringCGLIB$$0.<our-method-name>(<generated>)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
	at org.springframework.scheduling.support.ScheduledMethodRunnable.runInternal(ScheduledMethodRunnable.java:130)
	at org.springframework.scheduling.support.ScheduledMethodRunnable.lambda$run$2(ScheduledMethodRunnable.java:124)
	at io.micrometer.observation.Observation.observe(Observation.java:499)
	at org.springframework.scheduling.support.ScheduledMethodRunnable.run(ScheduledMethodRunnable.java:124)
	at org.springframework.scheduling.support.DelegatingErrorHandlingRunnable.run(DelegatingErrorHandlingRunnable.java:54)
	at java.base/java.lang.VirtualThread.run(Unknown Source)

The MongoLockProvider that I have mentioned above is catching the MongoServerException which the MongoCommandExceptions extends.