Regression: preserve message order when scheduled to the same time

[dazewell]

Repro

1. schedule message "1" to 12:34
2. schedule message "2" to 12:34

Expected

Message "1" is first.
Message "2" is second.

Actual

Message "2" is first.
Message "1" is second.

Official Telegram behavior

Message "1" is first.
Message "2" is second.

Why

This happens because of the recently added rounding to the closest minute when scheduling a message. Official Telegram is not doing that so if Message "1" is scheduled at 10:00:01 for 12:34, and if Message "2" is scheduled at 10:00:08 for 12:34, then they save their "seconds" component under the hood and this helps to preserve the relative order of the messages upon scheduling.

Rounding, instead, reverses the order and at some point start injecting messages around other messages (if the current clock second is >30 or not).

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: db044858-8dc8-4ceb-8baa-53e3331aa847

📥 Commits

Reviewing files that changed from the base of the PR and between 918dd4e and 5722244.

📒 Files selected for processing (1)

• TMessagesProj/src/main/java/tw/nekomimi/nekogram/helpers/ScheduleTimeHelper.java

---

📝 Walkthrough

Summary by CodeRabbit

• Bug Fixes
  • Fixed scheduled message delivery order to ensure messages scheduled for the same minute are delivered in the order they were created, matching Telegram's default behavior.

Walkthrough

The PR modifies ScheduleTimeHelper.getTargetTimeFromNow() to return unrounded millisecond-precision timestamps instead of rounding up to the next minute boundary. Added comments explain that this preserves distinct delivery timestamps for messages with identical display minutes and ensures they are delivered in creation order, matching Telegram's default behavior.

Changes

Schedule Timestamp Precision

Layer / File(s)	Summary
Millisecond-precision scheduling calculation TMessagesProj/src/main/java/tw/nekomimi/nekogram/helpers/ScheduleTimeHelper.java	getTargetTimeFromNow() now returns System.currentTimeMillis() + minutes * 60 * 1000L directly instead of rounding to the next minute, with added inline comments explaining that exact millisecond timestamps preserve distinct delivery order for messages displayed with the same minute.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: fixing a regression where message ordering is not preserved when multiple messages are scheduled to the same time.
Description check	✅ Passed	The description clearly explains the issue with reproduction steps, expected vs actual behavior, root cause analysis, and comparison to official Telegram behavior—all directly related to the changeset.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[risin42]

This PR changes the target minute for relative scheduling, while the reported issue is ordering within the same scheduled minute. Those are different behaviors, so the fix does not match the repro.