Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@app/src/main/java/me/capcom/smsgateway/modules/localserver/domain/PostMessageRequest.kt`:
- Around line 52-55: The current init validation in PostMessageRequest allows
scheduleAt == now; change the check so scheduleAt must be strictly in the
future. In the PostMessageRequest init block (the validation using
scheduleAt?.before(Date())), replace that conditional with a strict future check
such as verifying scheduleAt?.after(Date()) == true (and throw
IllegalArgumentException if it is not) so any scheduleAt equal to or before now
is rejected.

In
`@app/src/main/java/me/capcom/smsgateway/modules/messages/workers/SendMessagesWorker.kt`:
- Around line 121-124: In SendMessagesWorker.startAt() the call to
WorkManager.enqueueUniqueWork(...) uses the fixed SCHEDULED_NAME with
ExistingWorkPolicy.REPLACE which causes later scheduled messages to overwrite
earlier ones; change this to either generate a per-message unique work ID (e.g.,
include the message ID in the unique name passed to enqueueUniqueWork) or switch
the policy to ExistingWorkPolicy.KEEP so earlier scheduled work isn't replaced;
update the unique name creation and the enqueueUniqueWork(...) invocation
accordingly.

In `@README.md`:
- Around line 203-210: Update the curl example's scheduleAt value to a truly
future ISO-8601 timestamp so the sample matches the "future delivery" text: edit
the code block containing the curl POST example and replace the scheduleAt value
(currently "2026-04-05T09:00:00Z") with a future date/time (e.g.,
"2027-04-05T09:00:00Z") while keeping the same JSON structure and header usage;
ensure the token name scheduleAt and the POST example remain unchanged except
for the timestamp.

---

Nitpick comments:
In `@app/src/main/assets/api/swagger.json`:
- Around line 606-610: Add the OpenAPI date-time format to the timestamp string
fields: update the schema entries for scheduleAt and validUntil to include
format: "date-time" (in addition to type: "string") so they follow the same
RFC3339 pattern used by other timestamp fields like receivedAt and enable proper
code generation/validation.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/java/me/capcom/smsgateway/data/dao/MessagesDao.kt`:
- Around line 59-60: The query in nextScheduledTime() currently uses
COALESCE(scheduleAt, 0) which mixes types; change the SQL to explicitly exclude
NULL scheduleAt values so it returns the minimum scheduled time for messages
that have an actual schedule: replace the query with "SELECT MIN(scheduleAt)
FROM message WHERE state = 'Pending' AND scheduleAt IS NOT NULL" and keep the
function signature fun nextScheduledTime(): Long? so when no scheduled messages
exist it still returns null (or handle null at call sites to treat as 0 if
desired).

---

Nitpick comments:
In `@app/src/main/assets/api/swagger.json`:
- Around line 606-610: The OpenAPI schema for the scheduleAt property lacks an
explicit format; update the scheduleAt schema in swagger.json to include
"format": "date-time" alongside its "type": "string" and existing
description/example so client generators and validators recognize it as an
RFC3339 timestamp.

In `@app/src/main/java/me/capcom/smsgateway/modules/gateway/GatewayService.kt`:
- Around line 240-248: GatewayService is currently mapping GatewayApi.Message
into SendParams without validating scheduleAt, causing cloud requests to accept
past scheduleAt values unlike PostMessageRequest (see its init block). Add the
same server-side validation in GatewayService before creating SendParams: if
message.scheduleAt is non-null and is before the current time, reject the
request (return/throw the same BadRequest/validation error used by
PostMessageRequest) so cloud messages mirror local API behavior; implement this
check adjacent to the mapping code that constructs SendParams.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/java/me/capcom/smsgateway/data/dao/MessagesDao.kt`:
- Around line 59-60: The MIN query in MessagesDao.nextScheduledTime() is
operating on ISO-8601 TEXT (scheduleAt) and returning an invalid Long, breaking
the scheduleAt < earliest comparison in MessagesService.kt; fix by changing the
DAO query to convert the ISO-8601 TEXT to epoch milliseconds in SQL (use
SQLite's strftime('%s', scheduleAt) * 1000, with COALESCE/null handling) so
nextScheduledTime() returns the correct millisecond epoch Long?, and ensure
Converters.dateToString()/storage remains consistent or migrate to INTEGER epoch
storage if you prefer.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/java/me/capcom/smsgateway/data/dao/MessagesDao.kt`:
- Around line 59-60: The problem is nextScheduledTime() returns the post-insert
global minimum, so MessagesService.enqueueMessage() can't detect when the newly
inserted message became the earliest; to fix, read the previous minimum before
inserting rather than after: in MessagesService.enqueueMessage() call
dao.nextScheduledTime() to capture priorMin, then perform
messages.enqueue(request) (or insert), then call dao.nextScheduledTime() again
and compare against priorMin to decide whether to force
SendMessagesWorker.start(force=true). Alternatively, if you prefer a DAO-based
fix, add a new DAO method like nextScheduledTimeExcluding(excludeId: Long) with
SQL excluding that id (e.g., WHERE state='Pending' AND id != :excludeId) and use
it to compare correctly; reference nextScheduledTime(),
MessagesService.enqueueMessage(), messages.enqueue(request), and
SendMessagesWorker.start(force).
- Around line 59-60: The query in MessagesDao.nextScheduledTime() uses the
sqlite-specific unixepoch() function which may not exist on older Android SQLite
builds; replace unixepoch(MIN(`scheduleAt`)) * 1000 with CAST(strftime('%s',
MIN(`scheduleAt`)) AS INTEGER) * 1000 (or simply strftime('%s',
MIN(`scheduleAt`)) * 1000) to compute milliseconds in a portable way, update the
`@Query` string accordingly in the MessagesDao interface so nextScheduledTime()
returns the same epoch-ms value without relying on unixepoch().

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/java/me/capcom/smsgateway/modules/messages/MessagesService.kt`:
- Around line 99-110: After processing pending messages, add reschedule logic at
the end of sendPendingMessages() (or in doWork() after successful completion) to
query dao.nextScheduledTime(), and if it returns a future timestamp scheduleAt >
System.currentTimeMillis(), call SendMessagesWorker.start(context, /* earliest =
*/ determine whether this next scheduled time is the earliest via
dao.nextScheduledTime() compared to any in-memory/queued state or reuse the
existing earliest computation logic, and pass scheduleAt) so the worker is
started for the next pending scheduled message; use the same
SendMessagesWorker.start(...) signature as in MessagesService.enqueue block and
ensure you only start when there is a valid future scheduleAt.

In
`@app/src/main/java/me/capcom/smsgateway/modules/messages/workers/SendMessagesWorker.kt`:
- Around line 80-91: The start(...) method in SendMessagesWorker currently calls
setExpedited(...) while also setting a non-zero initialDelay, which causes
WorkManager to throw "Expedited jobs cannot be delayed"; fix by removing the
.setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST) call or
wrapping it so it is only applied when initialDelay == 0 before building the
OneTimeWorkRequestBuilder; keep the existing setBackoffCriteria(...) and
setInitialDelay(...) logic intact and ensure the builder only receives
setExpedited when initialDelay is zero.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/java/me/capcom/smsgateway/modules/messages/MessagesService.kt`:
- Around line 101-103: The computed earliest flag in MessagesService.kt is wrong
because dao.nextScheduledTime() returns 0 when no pending scheduled messages,
making the comparison it.time < 0 always false; update the logic where earliest
is computed (the val earliest using request.params.scheduleAt and
dao.nextScheduledTime()) to treat a 0/absent nextScheduledTime as "no next" by
substituting a sentinel like Long.MAX_VALUE (or checking == 0) before comparing,
e.g. compute val next = dao.nextScheduledTime() ?: 0L; if (next == 0L) consider
earliest = true; otherwise set earliest = it.time < next so the first scheduled
message correctly becomes the earliest and the worker scheduling
(ExistingWorkPolicy.KEEP) behaves as intended.

---

Outside diff comments:
In `@app/src/main/java/me/capcom/smsgateway/modules/messages/MessagesService.kt`:
- Around line 92-113: In enqueueMessage (MessagesService.enqueueMessage) remove
the second duplicate call to messages.enqueue(request) that appears after
computing earliest/scheduleAt; the message is already persisted by the first
try/catch block (which throws ConflictException on SQLiteConstraintException),
so delete the later messages.enqueue(request) and ensure the existing local
variable message (MessageWithRecipients) is used when scheduling via
SendMessagesWorker.start(context, earliest, scheduleAt) or
SendMessagesWorker.start(context, priority >= Message.PRIORITY_EXPEDITED, 0) and
returned at the end.

---

Duplicate comments:
In
`@app/src/main/java/me/capcom/smsgateway/modules/localserver/domain/messages/PostMessageRequest.kt`:
- Around line 44-48: The init validation in PostMessageRequest currently allows
scheduleAt equal to now because it only checks before(Date()); update the check
to reject values that are not strictly after the current time (i.e., treat
equal-to-now as invalid). Modify the init block around scheduleAt (in class
PostMessageRequest) to detect when scheduleAt is non-null and not after the
current Date (for example, using scheduleAt != null && !scheduleAt.after(Date())
or scheduleAt.time <= Date().time) and throw the same
IllegalArgumentException("scheduleAt must be in the future") in that case.

In `@app/src/main/java/me/capcom/smsgateway/modules/messages/MessagesService.kt`:
- Around line 107-111: After processing due messages in sendPendingMessages(),
query dao.nextScheduledTime() and if it returns a future timestamp scheduleAt >
System.currentTimeMillis(), call SendMessagesWorker.start(...) to schedule the
worker for that nextScheduledTime so remaining scheduled messages are picked up;
use the same start signature used elsewhere in this file
(SendMessagesWorker.start(context, <priorityFlagOrEarliest>, scheduleAt)) and
ensure you only reschedule when there are pending future messages returned by
dao.nextScheduledTime().

In
`@app/src/main/java/me/capcom/smsgateway/modules/messages/workers/SendMessagesWorker.kt`:
- Around line 80-91: The start function in SendMessagesWorker currently always
calls setExpedited(...) while also setting a non-zero initialDelay which will
throw IllegalArgumentException; fix by applying expedited only when initialDelay
== 0: compute initialDelay as you already do, create the
OneTimeWorkRequestBuilder<SendMessagesWorker>(), and conditionally call
setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST) only if
initialDelay == 0 (otherwise skip that call) before setting backoff criteria,
setInitialDelay(initialDelay, TimeUnit.MILLISECONDS) and build the request so
scheduled messages are not marked expedited.

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@app/src/main/java/me/capcom/smsgateway/modules/messages/MessagesService.kt`:
- Around line 210-251: The reschedule block after the while(true) is dead
because messages.getPending(settings.processingOrder) uses ?: return to exit the
loop; move the scheduled-message check so it executes when getPending returns
null before returning. Specifically, inside the processing loop where you call
messages.getPending(... ) ?: return, replace that return with logic that calls
dao.nextScheduledTime(), compares it to System.currentTimeMillis(), and if a
future time exists call SendMessagesWorker.start(context, /* earliest= */ true,
nextScheduledTime) (or compute earliest as needed) and then return; keep
existing flow for applyLimit(), sendMessage(...), previousPriority and
settings.sendIntervalRange unchanged. Ensure you reference messages.getPending,
dao.nextScheduledTime, SendMessagesWorker.start, sendMessage and
previousPriority when editing.

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In
`@app/src/main/java/me/capcom/smsgateway/modules/localserver/routes/MessagesRoutes.kt`:
- Around line 317-355: The toDomain() mapper for MessageWithRecipients does not
populate the domain Message.scheduleAt, so scheduled messages come back without
their timestamp; update MessageWithRecipients.toDomain (used for
POST/list/detail) to set the domain Message's scheduleAt by mapping the
persisted value (e.g., message.scheduleAt or message.scheduledAt) into the
domain type (convert to Date if needed) when constructing
me.capcom.smsgateway.modules.localserver.domain.messages.Message so responses
include the scheduled timestamp.
- Around line 242-258: The code builds a SendRequest with request.scheduleAt but
never validates that scheduleAt is in the future; add a guard in the request
handler (where SendRequest is constructed in MessagesRoutes.kt) to check if
request.scheduleAt != null and request.scheduleAt <= now, and if so respond with
a 400 Bad Request (or equivalent error flow) rejecting the request before
creating SendRequest or enqueueing; use the same time type used elsewhere
(Date/Instant) to compare against current time, and reference SendRequest,
SendParams and the handler code that currently constructs them to locate where
to add the validation.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@app/src/main/java/me/capcom/smsgateway/modules/localserver/domain/messages/PostMessageRequest.kt`:
- Around line 83-85: PostMessageRequest currently only checks scheduleAt is in
the future but not that it occurs before message expiry; update the validation
inside PostMessageRequest (check where scheduleAt is validated) to also reject
scheduleAt that is after the message's expiry by comparing scheduleAt against
the request's expiration parameters (use validUntil if present, otherwise
compute expiry from ttl) and throw an IllegalArgumentException (e.g.,
"scheduleAt must be before message expiry") when scheduleAt is >= expiry;
reference the scheduleAt, validUntil, ttl fields and the PostMessageRequest
validation block so the check covers both expiry semantics.

---

Duplicate comments:
In
`@app/src/main/java/me/capcom/smsgateway/modules/localserver/domain/messages/PostMessageRequest.kt`:
- Around line 90-93: The init block in PostMessageRequest currently checks
scheduleAt?.before(Date()) allowing scheduleAt == now while validate() uses a
stricter comparison; update the constructor/init to use the same strict future
check as validate() (e.g., compare scheduleAt.time <=
System.currentTimeMillis()) or centralize the validation into the validate()
method and call it from the init so both construction and validate() enforce
identical "must be in the future" logic; locate PostMessageRequest, its init
block and the validate() method to make the change.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@app/src/main/java/me/capcom/smsgateway/modules/localserver/domain/messages/PostMessageRequest.kt`:
- Around line 83-94: Remove the redundant init block that performs the same
scheduleAt check as validate(); specifically delete the init { if
(scheduleAt?.before(Date()) == true) { throw
IllegalArgumentException("scheduleAt must be in the future") } } so only
validate() enforces the rule (it uses scheduleAt?.after(Date()) == false which
is the intended stricter semantics); keep validate(), scheduleAt property and
callers such as MessagesRoutes.kt that call .validate() and ensure no other
implicit initialization checks remain.

---

Nitpick comments:
In `@app/src/main/java/me/capcom/smsgateway/modules/messages/MessagesService.kt`:
- Line 81: Call sites use the magic literal 0 for immediate scheduling in
SendMessagesWorker.start(context, ..., 0); replace this with a named constant or
overload to make intent explicit — e.g., add IMMEDIATE_SCHEDULE = 0L (or
IMMEDIATE = 0L) as a public constant on SendMessagesWorker and update calls to
SendMessagesWorker.start(context, false, SendMessagesWorker.IMMEDIATE), or add a
default parameter scheduleAt: Long = IMMEDIATE and/or an overload start(context,
force: Boolean) that delegates to start(context, force, IMMEDIATE); update all
occurrences (including the other start calls) to use the new constant/overload.
- Around line 207-250: The finally block in sendPendingMessages currently always
calls SendMessagesWorker.start(...) (using dao.nextScheduledTime()) even when
the coroutine was cancelled; change this so rescheduling only happens on normal
completion: either (A) catch CancellationException and rethrow, then in finally
check coroutineContext[Job]?.isActive (or a local flag set on normal exit)
before calling SendMessagesWorker.start, or (B) remove the reschedule from
sendPendingMessages and instead invoke SendMessagesWorker.start(...) from the
caller (e.g., SendMessagesWorker.doWork()) after sendPendingMessages returns
successfully; reference sendPendingMessages, SendMessagesWorker.start,
dao.nextScheduledTime and doWork to locate where to apply the change.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/java/me/capcom/smsgateway/modules/messages/MessagesService.kt`:
- Around line 212-257: The finally block in sendPendingMessages() reschedules
work even after cancellation; remove the redundant catch(CancellationException)
and gate the reschedule so it only runs when the coroutine completed normally
(i.e., not cancelled). Concretely, import kotlin.coroutines.coroutineContext,
remove the catch block, and in the finally of sendPendingMessages() check
coroutineContext.isActive (or !coroutineContext.isActive to skip) before calling
SendMessagesWorker.start(...); this ensures SendMessagesWorker.start is not
invoked when stop()/cancellation occurred.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/java/me/capcom/smsgateway/data/dao/MessagesDao.kt`:
- Around line 59-60: nextScheduledTime() loses milliseconds because
strftime('%s', ...) yields whole seconds; update the `@Query` to compute epoch
milliseconds using a millisecond-preserving expression (e.g. convert
julianday(scheduleAt) to epoch ms via (julianday(scheduleAt) - 2440587.5) *
86400000) and remove COALESCE nullability handling if you keep COALESCE 0 then
change the Kotlin return type from Long? to Long to reflect non-null; locate the
SQL in the MessagesDao.nextScheduledTime() definition and adjust both the SQL
expression and the function signature accordingly.

---

Outside diff comments:
In
`@app/src/main/java/me/capcom/smsgateway/modules/messages/workers/SendMessagesWorker.kt`:
- Around line 79-107: The current start function in SendMessagesWorker uses a
single unique NAME for both immediate (initialDelay == 0L) and scheduled runs
which can drop expedited IMMEDIATE runs when a scheduled job exists; update
start to distinguish immediate vs scheduled runs by either (A) when initialDelay
== 0L (IMMEDIATE) always use ExistingWorkPolicy.REPLACE for the
enqueueUniqueWork call so expedited work replaces existing scheduled work, or
(B) introduce a second constant SCHEDULED_NAME and use NAME for immediate runs
and SCHEDULED_NAME for delayed runs so scheduled and immediate queues are
isolated; implement the chosen approach inside start where initialDelay is
computed and before calling WorkManager.getInstance(context).enqueueUniqueWork.

---

Nitpick comments:
In
`@app/src/main/java/me/capcom/smsgateway/modules/messages/workers/SendMessagesWorker.kt`:
- Around line 81-96: The start(...) method's scheduleAt: Long parameter is
ambiguous when callers pass 0L to mean "IMMEDIATE"; change the API to make
intent explicit by either (A) making scheduleAt nullable (scheduleAt: Long?)
where null means immediate and update SendMessagesWorker.start to compute
initialDelay when scheduleAt != null, or (B) add a separate entrypoint
startNow(context, force) and keep startAt(context, force, scheduleAt: Long) for
scheduled runs; update all callers in MessagesService to use the clearer
method/nullable contract and adjust the logic in OneTimeWorkRequestBuilder usage
and the initialDelay calculation accordingly so past timestamps and explicit
immediate requests are distinguishable.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/java/me/capcom/smsgateway/modules/messages/MessagesService.kt`:
- Around line 249-255: The final reschedule check currently only enqueues a
worker when dao.nextScheduledTime() > System.currentTimeMillis(), which drops
work that became due in the gap; change the logic to schedule whenever
dao.nextScheduledTime() != 0 and treat times <= System.currentTimeMillis() as
"due now" (i.e., call SendMessagesWorker.start(...) so it runs immediately when
nextScheduledTime <= now, otherwise schedule for the future), updating the call
site that uses coroutineContext, dao.nextScheduledTime() and
SendMessagesWorker.start(context, ...) accordingly.

---

Duplicate comments:
In `@app/src/main/java/me/capcom/smsgateway/modules/messages/MessagesService.kt`:
- Around line 97-100: The logic computing earliest in MessagesService is
treating nextScheduledTime() == 0 as non-earliest; change it so "no existing
scheduled message" (nextScheduled == 0L) counts as earliest. Update the block
that sets earliest (using request.params.scheduleAt and dao.nextScheduledTime())
to return true when scheduleAt is null OR when nextScheduled == 0L, otherwise
compare it.time < nextScheduled; reference the variables earliest,
request.params.scheduleAt and dao.nextScheduledTime() to locate and fix the
condition.

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@app/src/main/java/me/capcom/smsgateway/data/dao/MessagesDao.kt`:
- Around line 59-60: nextScheduledTime() loses millisecond precision and
declares a nullable return even though COALESCE forces a value; update the DAO
query used by nextScheduledTime() to compute epoch milliseconds without
truncating the fractional seconds (so MessagesService comparisons in
enqueueMessage and sendPendingMessages use full ms precision) and change the
method signature to return Long (non-nullable). You can do this by modifying the
SQL used in nextScheduledTime() to include the fractional seconds when
converting MIN(scheduleAt) to epoch-ms (or switch scheduleAt to stored INTEGER
epoch-ms via a TypeConverter) and ensure the function name nextScheduledTime()
is updated to return Long instead of Long?.

In `@app/src/main/java/me/capcom/smsgateway/modules/messages/MessagesService.kt`:
- Around line 249-256: The final reschedule drops rows that became due between
getPending and the check because you only reschedule when nextScheduledTime >
System.currentTimeMillis(); change the logic in the finally block (referencing
coroutineContext.isActive, dao.nextScheduledTime(), and
SendMessagesWorker.start) so that when dao.nextScheduledTime() returns a
non-zero time you always re-arm the worker: if the time is <=
System.currentTimeMillis() start the worker to process immediately, otherwise
schedule it for the future timestamp; this ensures messages that became due
during the race are not stranded.