app/schemas/me.capcom.smsgateway.data.AppDatabase/17.json (1)

341-344: Consider adding an index on webhook_id if individual webhook queries are expected.

There's no index on webhook_id alone. If you anticipate queries that filter or group by webhook_id (e.g., getting all pending items for a specific webhook), an additional index could improve performance. However, if such queries are not planned, the current indices are sufficient.

Also applies to: 391-412

app/src/main/java/me/capcom/smsgateway/modules/webhooks/WebHooksService.kt (1)

153-168: Move get<Context>() outside the loop to avoid redundant DI lookups.

get<Context>() is called on every iteration. Since the context doesn't change, retrieve it once before the loop.

+        val context = get<Context>()
+        
         webhooksToProcess.forEach { webhook ->
             // ... existing skip logic ...
             
             try {
                 // Create the webhook event DTO
                 val webhookEventDTO = WebHookEventDTO(
                     id = NanoIdUtils.randomNanoId(),
                     webhookId = webhook.id,
                     event = event,
                     deviceId = deviceId,
                     payload = payload,
                 )

                 SendWebhookWorker.start(
-                    context = get<Context>(),
+                    context = context,
                     url = webhook.url,
                     data = webhookEventDTO,
                     internetRequired = webhooksSettings.internetRequired
                 )

app/src/main/java/me/capcom/smsgateway/modules/webhooks/db/WebhookStatus.kt (1)

24-27: Consider using entries instead of values() for future Kotlin compatibility.

values() works but entries is the recommended approach in modern Kotlin.

     companion object {
         fun fromValue(value: String): WebhookStatus? {
-            return values().find { it.value == value }
+            return entries.find { it.value == value }
         }

app/src/main/java/me/capcom/smsgateway/modules/webhooks/db/WebhookQueueEntity.kt (1)

36-40: Consider adding defaultValue to createdAt and nextAttempt for schema consistency.

These columns have Kotlin defaults but lack Room defaultValue annotations. While Kotlin defaults work for normal inserts via the DAO, adding schema defaults ensures consistency if raw SQL or migrations ever insert rows directly.

-    @ColumnInfo(name = "created_at")
+    @ColumnInfo(name = "created_at", defaultValue = "0")
     val createdAt: Long = System.currentTimeMillis(),

-    @ColumnInfo(name = "next_attempt")
+    @ColumnInfo(name = "next_attempt", defaultValue = "0")
     val nextAttempt: Long = System.currentTimeMillis(),

Note: SQLite doesn't support CURRENT_TIMESTAMP for INTEGER columns directly, so 0 is a placeholder; the actual default will still come from Kotlin.

app/src/main/java/me/capcom/smsgateway/modules/webhooks/db/WebhookQueueDao.kt (1)

32-43: Inconsistent string quoting in SQL queries.

The query uses double quotes ("pending", "failed") while other queries like scheduledWebhooksCount use single quotes ('pending', 'failed'). While SQLite accepts both, single quotes are SQL standard for string literals.

     @Query(
         """
         SELECT * FROM webhook_queue 
-        WHERE status IN ("pending", "failed") AND next_attempt <= :currentTime 
+        WHERE status IN ('pending', 'failed') AND next_attempt <= :currentTime 
         ORDER BY next_attempt ASC 
         LIMIT :limit
     """
     )

Apply similar changes to other queries using double quotes (lines 51, 65, 84, 98, 130, 142).

app/src/main/java/me/capcom/smsgateway/modules/webhooks/db/WebhookQueueRepository.kt (1)

111-118: Consider adding a maximum cap to prevent excessive backoff delays.

With configurable maxRetries, high retry counts could produce impractical delays (e.g., retryCount=20 → ~30 days). Consider capping the delay:

     private fun calculateBackoffDelay(retryCount: Int, baseDelayMs: Long): Long {
         // Exponential backoff: baseDelay * 2^(retryCount - 1)
-        val multiplier = (1L shl (retryCount - 1))
-        return baseDelayMs * multiplier
+        val multiplier = (1L shl minOf(retryCount - 1, 10)) // Cap at 2^10 = 1024x
+        return minOf(baseDelayMs * multiplier, MAX_BACKOFF_DELAY_MS)
     }
+
+    companion object {
+        private const val MAX_BACKOFF_DELAY_MS = 3600_000L // 1 hour max
+    }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

app/src/main/java/me/capcom/smsgateway/modules/webhooks/workers/WebhookQueueProcessorWorker.kt (2)

359-361: Critical: client.close() in finally closes wrong HttpClient instance (duplicate issue).

This issue was flagged in previous reviews but remains unresolved. The client property is a getter that creates a new HttpClient on each access. Line 293's client.post(url) creates HttpClient #1, while line 360's client.close() creates HttpClient #2 and closes it. HttpClient #1 leaks.

Remove client.close() from the finally block:

-            } finally {
-                client.close()
-            }

The client lifecycle should be managed at the batch or worker level after fixing the client initialization (see separate comment on lines 405-423).

---

405-423: Critical: Client getter creates new HttpClient on every access, causing resource leaks (duplicate issue).

This issue was flagged in previous reviews but remains unresolved. The client property is a getter (get() = ...) that instantiates a new HttpClient every time it's accessed. Each unclosed client leaks connections, threads, and memory.

Use lazy initialization to create a single, reusable client:

-    private val client
-        get() = HttpClient(OkHttp) {
+    private val client by lazy {
+        HttpClient(OkHttp) {
             install(HttpTimeout) {
                 requestTimeoutMillis = PROCESSING_TIMEOUT_MS
                 connectTimeoutMillis = 5000
                 socketTimeoutMillis = 5000
             }
             install(ContentNegotiation) {
                 gson {
                     configure()
                 }
             }
             install(DefaultRequest) {
                 userAgent("${BuildConfig.APPLICATION_ID}/${BuildConfig.VERSION_NAME}")
             }
             install(PayloadSingingPlugin) {
                 secretKeyProvider = { settings.signingKey }
             }
         }
+    }

Then close the client once at the end of doWork() before returning success, or rely on worker termination to clean up.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

app/src/main/java/me/capcom/smsgateway/modules/webhooks/workers/WebhookQueueProcessorWorker.kt (2)

368-370: Duplicate: client.close() in finally block is problematic.

As noted in past review comments, closing the client in the finally block is incorrect. Due to the client property being a getter (see lines 414-432), this creates a new HttpClient instance and closes it, leaving the actual client used on line 302 unclosed. Once the client property is fixed to use lazy initialization, this close call should be removed from here and moved to the end of batch processing or worker lifecycle.

---

414-432: Duplicate: Critical resource leak—client getter creates new instances on each access.

As detailed in past review comments, the client property is a getter that instantiates a new HttpClient every time it's accessed. On line 302, client.post(url) creates HttpClient #1, and on line 369, client.close() creates HttpClient #2 and closes it, leaving HttpClient #1 open and leaking connections/threads.

The fix is to use lazy initialization:

private val client by lazy {
    HttpClient(OkHttp) {
        install(HttpTimeout) {
            requestTimeoutMillis = PROCESSING_TIMEOUT_MS
            connectTimeoutMillis = 5000
            socketTimeoutMillis = 5000
        }
        install(ContentNegotiation) {
            gson {
                configure()
            }
        }
        install(DefaultRequest) {
            userAgent("${BuildConfig.APPLICATION_ID}/${BuildConfig.VERSION_NAME}")
        }
        install(PayloadSingingPlugin) {
            secretKeyProvider = { settings.signingKey }
        }
    }
}

Then remove the client.close() from the finally block in sendWebhook() and instead close the client once at the end of doWork() or when the worker completes.

app/src/main/java/me/capcom/smsgateway/modules/webhooks/workers/WebhookQueueProcessorWorker.kt (2)

148-151: Optional: The fixed delay when idle may lead to unnecessary database polling.

When processedCount == 0, the worker delays 5 seconds then immediately checks hasScheduledWebhooks() again (which queries the database). If the queue remains empty for extended periods, this results in repeated DB queries every 5 seconds. Consider exiting the loop when the queue is empty and relying on external triggers (e.g., enqueuing new webhooks) to restart the worker.

---

334-355: Combine redundant exception handlers.

Both IllegalArgumentException and JSONException handlers perform identical actions (log error, return false). They can be combined for brevity.

Apply this diff:

-            } catch (e: IllegalArgumentException) {
+            } catch (e: Exception) {
+                when (e) {
+                    is IllegalArgumentException, is JSONException -> {
+                        logsSvc.insert(
+                            priority = LogEntry.Priority.ERROR,
+                            module = NAME,
+                            message = "Webhook validation error: ${e.message}",
+                            context = mapOf(
+                                "webhookId" to webhook.id,
+                                "error" to e.message
+                            )
+                        )
+                        false
+                    }
+                    else -> throw e
+                }
+            } catch (e: Throwable) {
                 logsSvc.insert(
-                    priority = LogEntry.Priority.ERROR,
+                    priority = LogEntry.Priority.WARN,
                     module = NAME,
-                    message = "Webhook invalid argument: ${e.message}",
+                    message = "Webhook network error: ${e.message}",
                     context = mapOf(
                         "webhookId" to webhook.id,
-                        "error" to e.message
+                        "error" to e.message,
+                        "retryCount" to webhook.retryCount
                     )
                 )
-                false
-            } catch (e: JSONException) {
-                logsSvc.insert(
-                    priority = LogEntry.Priority.ERROR,
-                    module = NAME,
-                    message = "Webhook JSON error: ${e.message}",
-                    context = mapOf(
-                        "webhookId" to webhook.id,
-                        "error" to e.message
-                    )
-                )
-                false
-            } catch (e: Throwable) {
-                logsSvc.insert(
-                    priority = LogEntry.Priority.WARN,
-                    module = NAME,
-                    message = "Webhook network error: ${e.message}",
-                    context = mapOf(
-                        "webhookId" to webhook.id,
-                        "error" to e.message,
-                        "retryCount" to webhook.retryCount
-                    )
-                )
-                false // Network errors should trigger retry
+                false
+            }

Or more simply:

-            } catch (e: IllegalArgumentException) {
-                logsSvc.insert(
-                    priority = LogEntry.Priority.ERROR,
-                    module = NAME,
-                    message = "Webhook invalid argument: ${e.message}",
-                    context = mapOf(
-                        "webhookId" to webhook.id,
-                        "error" to e.message
-                    )
-                )
-                false
-            } catch (e: JSONException) {
+            } catch (e: Exception) {
+                when (e) {
+                    is IllegalArgumentException, is JSONException -> {
                 logsSvc.insert(
                     priority = LogEntry.Priority.ERROR,
                     module = NAME,
-                    message = "Webhook JSON error: ${e.message}",
+                    message = "Webhook validation error: ${e.message}",
                     context = mapOf(
                         "webhookId" to webhook.id,
                         "error" to e.message
                     )
                 )
                 false
-            } catch (e: Throwable) {
+                    }
+                    else -> {
                 logsSvc.insert(
                     priority = LogEntry.Priority.WARN,
                     module = NAME,
                     message = "Webhook network error: ${e.message}",
                     context = mapOf(
                         "webhookId" to webhook.id,
                         "error" to e.message,
                         "retryCount" to webhook.retryCount
                     )
                 )
-                false // Network errors should trigger retry
+                        false
+                    }
+                }
+            }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

app/src/main/java/me/capcom/smsgateway/modules/webhooks/workers/SendWebhookWorker.kt (1)

225-230: runBlocking blocks the calling thread.

start() is called from coroutine scopes in EventsReceiver, and runBlocking blocks the dispatcher thread. Consider making start() a suspend function or using a different approach.

Options to address this:

1. Make start() a suspend function and update callers
2. Use CoroutineScope(Dispatchers.IO).launch { ... } for fire-and-forget (but loses error propagation)
3. Accept a CoroutineScope parameter for structured concurrency

app/src/main/java/me/capcom/smsgateway/modules/webhooks/workers/WebhookQueueProcessorWorker.kt (1)

414-432: Critical: HttpClient getter still creates new instance on each access.

The client property uses get() = which instantiates a new HttpClient on every access. In sendWebhook():

1. Line 302: client.post(url) creates HttpClient #1
2. Line 369: client.close() creates HttpClient #2 and closes it

HttpClient #1 is never closed, causing connection/thread leaks across the batch.

-    private val client
-        get() = HttpClient(OkHttp) {
+    private val client by lazy {
+        HttpClient(OkHttp) {
             install(HttpTimeout) {
                 requestTimeoutMillis = PROCESSING_TIMEOUT_MS
                 connectTimeoutMillis = 5000
                 socketTimeoutMillis = 5000
             }
             install(ContentNegotiation) {
                 gson {
                     configure()
                 }
             }
             install(DefaultRequest) {
                 userAgent("${BuildConfig.APPLICATION_ID}/${BuildConfig.VERSION_NAME}")
             }
             install(PayloadSingingPlugin) {
                 secretKeyProvider = { settings.signingKey }
             }
         }
+    }

Then remove client.close() from the finally block in sendWebhook() (line 369) and add cleanup at the end of doWork() before returning success.

app/src/main/java/me/capcom/smsgateway/modules/webhooks/db/WebhookQueueRepository.kt (1)

59-83: Consider handling missing webhook in scheduleRetry.

dao.getById(webhookId) at line 65 may throw if the webhook was deleted. The caller (handleWebhookFailure) catches exceptions, but explicit handling would be cleaner.

     suspend fun scheduleRetry(
         webhookId: Long,
         error: String?,
         maxRetries: Int = 3,
         baseDelayMs: Long = 5000L
     ) {
-        val webhook = dao.getById(webhookId)
+        val webhook = dao.getById(webhookId) ?: run {
+            // Webhook was deleted, nothing to retry
+            return
+        }

This requires changing getById to return WebhookQueueEntity? or keeping the current behavior where the exception propagates to handleWebhookFailure.

app/src/main/java/me/capcom/smsgateway/modules/webhooks/workers/SendWebhookWorker.kt (1)

157-159: Catching Throwable includes unrecoverable JVM errors.

Similar to the issue fixed in WebhookQueueProcessorWorker, consider catching Exception instead.

-        } catch (e: Throwable) {
+        } catch (e: Exception) {
             e.printStackTrace()
             return Result.Retry(e.message ?: e.toString())

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

app/src/main/java/me/capcom/smsgateway/modules/webhooks/workers/SendWebhookWorker.kt (1)

210-231: Avoid runBlocking inside start() to prevent blocking coroutine threads.

start() uses runBlocking to call the suspend enqueueWebhook(). When start() is invoked from coroutine-based flows (as in EventsReceiver/WebHooksService), this blocks the dispatcher thread and can hurt responsiveness or deadlock if used on a constrained dispatcher.

Prefer exposing a suspend API (e.g. suspend fun start(...)) or delegating enqueueing to a caller-owned CoroutineScope instead of runBlocking.

app/schemas/me.capcom.smsgateway.data.AppDatabase/17.json (1)

331-414: Webhook queue schema matches the entity; revisit payload limits and cleanup indexing.

The webhook_queue table definition and its composite indices line up with WebhookQueueEntity and the DAO queries (status + next_attempt and status + created_at), so the schema is consistent.

Operationally, the earlier points still apply:

• retry_count is tracked but max retries are enforced only in application logic; make sure this coupling is documented.
• payload is an unbounded TEXT; consider validating payload size at enqueue time to avoid unbounded growth.
• Cleanup queries rely on created_at; if you see heavy cleanup traffic, a dedicated created_at index (in addition to the composite one) could be worthwhile.

app/src/main/java/me/capcom/smsgateway/modules/webhooks/db/WebhookQueueDao.kt (2)

20-21: Make getById return nullable to avoid crashes on missing rows.

Declaring getById as returning a non-null WebhookQueueEntity means Room will throw if the ID is not found. Returning WebhookQueueEntity? lets callers handle “not found” gracefully.

@Query("SELECT * FROM webhook_queue WHERE id = :id")
suspend fun getById(id: Long): WebhookQueueEntity?

Then adjust callers to handle a null result.

---

48-57: Align markAsProcessing and recoverStuckProcessingWebhooks to avoid premature recovery.

recoverStuckProcessingWebhooks uses next_attempt < :timeoutThreshold to detect stuck items, but markAsProcessing only flips status = "processing" and leaves next_attempt unchanged. Under backlog, a webhook scheduled long ago but just started processing could immediately satisfy the timeout condition and be reset to pending while still in-flight.

Consider updating next_attempt when marking as processing so the timeout is measured from processing start, e.g.:

@Query(
    """
    UPDATE webhook_queue
    SET status = 'processing', next_attempt = :currentTime
    WHERE id = :id
    """
)
suspend fun markAsProcessing(
    id: Long,
    currentTime: Long = System.currentTimeMillis(),
)

Also applies to: 136-148

app/src/main/java/me/capcom/smsgateway/modules/webhooks/workers/SendWebhookWorker.kt (1)

48-53: Consider adding a Kotlin @Deprecated annotation in addition to KDoc.

You’ve documented deprecation in KDoc, but callers won’t get compiler warnings. Consider adding a @Deprecated annotation on SendWebhookWorker with a message and replacement (e.g. queue-based processing), so usage is surfaced at compile time.

app/src/main/java/me/capcom/smsgateway/modules/webhooks/WebHooksService.kt (1)

126-210: Emit logic and logging are solid; consider unifying log module naming.

The new emit() flow correctly:

• Filters webhooks by enabled source and available deviceId.
• Builds WebHookEventDTO per webhook.
• Queues via SendWebhookWorker.start() inside a per-item try/catch so one failure doesn’t short-circuit others.
• Logs both per-webhook results and a final summary.

One small nit: here you use "WebHooksService" as the module value in logs, while other places (e.g. SendWebhookWorker) use NAME = "webhooks". Aligning on a single module identifier would make log querying/aggregation easier.

app/src/main/java/me/capcom/smsgateway/modules/webhooks/db/WebhookQueueEntity.kt (1)

12-44: Entity mapping is consistent; consider sharing a single timestamp source if needed.

WebhookQueueEntity matches the webhook_queue schema and indices well, and the defaults for retryCount, status, and timestamps are sensible.

If you ever need createdAt and nextAttempt to be exactly identical on initial insert, consider deriving both from a single timestamp in the repository/factory instead of separate System.currentTimeMillis() defaults in the constructor.

app/src/main/java/me/capcom/smsgateway/modules/webhooks/db/WebhookQueueDao.kt (1)

110-122: Guard queue statistics aggregates against NULL on empty tables.

getQueueStatistics() uses SUM(CASE WHEN ...) projections mapped into non-null Int fields. Depending on SQLite behavior, SUM(...) can return NULL when there are no rows, which may not map cleanly into non-null Kotlin Ints.

To be defensive, you could wrap each aggregate with IFNULL(..., 0) so statistics are always zero-based when the queue is empty.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

app/src/main/java/me/capcom/smsgateway/modules/webhooks/WebHooksService.kt (3)

163-168: Consider passing Context as parameter for consistency.

The emit method uses get<Context>() to retrieve Context from Koin, while start/stop methods receive Context as a parameter. For consistency and easier testing, consider passing Context to emit() instead.

-    fun emit(event: WebHookEvent, payload: Any) {
+    fun emit(context: Context, event: WebHookEvent, payload: Any) {
         val webhooksToProcess = webHooksDao.selectByEvent(event)
         var queuedCount = 0
         var skippedCount = 0
 
         webhooksToProcess.forEach { webhook ->
             // ... skip logic ...
 
             try {
                 val webhookEventDTO = WebHookEventDTO(
                     id = NanoIdUtils.randomNanoId(),
                     webhookId = webhook.id,
                     event = event,
                     deviceId = deviceId,
                     payload = payload,
                 )
 
                 SendWebhookWorker.start(
-                    context = get<Context>(),
+                    context = context,
                     url = webhook.url,
                     data = webhookEventDTO,
                     internetRequired = webhooksSettings.internetRequired
                 )

---

172-181: Consider reducing logging verbosity for normal operations.

The per-webhook success log at DEBUG level may generate excessive logs when many webhooks are configured. Consider removing individual success logs and relying on the summary, or making them conditional on a verbose debug flag.

-                logsService.insert(
-                    LogEntry.Priority.DEBUG,
-                    NAME,
-                    "Queued webhook event for processing",
-                    mapOf(
-                        "webhookId" to webhook.id,
-                        "event" to event.name,
-                        "internetRequired" to webhooksSettings.internetRequired
-                    )
-                )
+                // Individual success logs removed; rely on summary

---

197-210: Log summary at higher priority when webhooks are skipped.

The summary always logs at DEBUG level, even when webhooks fail. Consider logging at WARN or ERROR when skippedCount > 0 to make failures more visible in production logs.

         // Log summary for debugging
         if (webhooksToProcess.isNotEmpty()) {
+            val priority = if (skippedCount > 0) LogEntry.Priority.WARN else LogEntry.Priority.DEBUG
             logsService.insert(
-                LogEntry.Priority.DEBUG,
+                priority,
                 NAME,
                 "Webhook emission summary",
                 mapOf(
                     "event" to event.name,
                     "totalWebhooks" to webhooksToProcess.size,
                     "queued" to queuedCount,
                     "skipped" to skippedCount
                 )
             )
         }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

app/src/main/java/me/capcom/smsgateway/modules/webhooks/workers/SendWebhookWorker.kt (1)

225-230: runBlocking blocks a coroutine dispatcher thread.

This concern was already raised in a previous review. The start() function is invoked from coroutine scopes in EventsReceiver, so using runBlocking here blocks a dispatcher thread unnecessarily. Consider making start() a suspend function or using a different approach to avoid blocking.

app/schemas/me.capcom.smsgateway.data.AppDatabase/17.json (1)

331-414: Webhook queue table schema is well-designed.

The webhook_queue table structure is appropriate for the persistent queue pattern:

• Auto-increment primary key for ordering
• Proper fields for retry tracking (retry_count, next_attempt, last_error)
• Status field with sensible default ('pending')
• Composite indices on (status, next_attempt) and (status, created_at) align with expected query patterns

Previous review comments regarding retry limit enforcement at the application level, payload size validation, and cleanup query optimization remain valid considerations for future iterations.

app/src/main/java/me/capcom/smsgateway/modules/webhooks/db/WebhookQueueDao.kt (2)

20-21: getById will crash if the record doesn't exist.

Room will throw an exception if no row matches the ID when the return type is non-nullable. Return nullable to handle missing records gracefully.

Apply this diff:

     @Query("SELECT * FROM webhook_queue WHERE id = :id")
-    suspend fun getById(id: Long): WebhookQueueEntity
+    suspend fun getById(id: Long): WebhookQueueEntity?

---

48-57: Recovery logic measures timeout from schedule time, not processing start.

markAsProcessing() doesn't update next_attempt, so recoverStuckProcessingWebhooks() at lines 136-148 checks next_attempt < :timeoutThreshold against when webhooks were scheduled, not when they started processing. This can incorrectly recover webhooks that just started.

Update markAsProcessing to set next_attempt to current time:

     @Query(
         """
         UPDATE webhook_queue 
-        SET status = "processing" 
+        SET status = 'processing', next_attempt = :currentTime
         WHERE id = :id
     """
     )
     suspend fun markAsProcessing(
         id: Long,
+        currentTime: Long = System.currentTimeMillis()
     )

app/src/main/java/me/capcom/smsgateway/modules/webhooks/workers/WebhookQueueProcessorWorker.kt (2)

414-432: Critical: client getter creates new HttpClient on each access, causing resource leaks.

The client property is a getter that instantiates a new HttpClient every time it's accessed:

• Line 302: client.post(url) creates HttpClient #1
• Line 369: client.close() creates HttpClient #2 and closes it

HttpClient #1 is never closed, leaking connections and threads.

Use lazy initialization:

-    private val client
-        get() = HttpClient(OkHttp) {
+    private val client by lazy {
+        HttpClient(OkHttp) {
             install(HttpTimeout) {
                 requestTimeoutMillis = PROCESSING_TIMEOUT_MS
                 connectTimeoutMillis = 5000
                 socketTimeoutMillis = 5000
             }
             install(ContentNegotiation) {
                 gson {
                     configure()
                 }
             }
             install(DefaultRequest) {
                 userAgent("${BuildConfig.APPLICATION_ID}/${BuildConfig.VERSION_NAME}")
             }
             install(PayloadSingingPlugin) {
                 secretKeyProvider = { settings.signingKey }
             }
         }
+    }

Then remove the finally block from sendWebhook() (see next comment) and optionally close the client once at the end of doWork() after line 166:

// Before return@withContext Result.success() at line 166
if (::client.isInitialized) {
    client.close()
}

---

368-370: Remove client.close() from the finally block.

Once the client is lazily initialized (per the previous comment), closing it here would prematurely terminate the client for subsequent webhooks in the batch. Remove this finally block entirely.

Apply this diff:

                 false // Network errors should trigger retry
-            } finally {
-                client.close()
-            }
+            }
         }

app/src/main/java/me/capcom/smsgateway/modules/webhooks/workers/SendWebhookWorker.kt (1)

210-210: Consider reusing Gson instance from class scope.

The gson instance in the companion object duplicates the pattern used in sendData() (line 138). Consider consolidating to a single shared instance to avoid redundant configuration.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro