fix: delegate MailData id generation to framework

[wisdommen]

Summary

• Remove timestamp-based primary key generation from MailData constructor
• Let the Framework insert-time UUID guard assign ids when id == null
• Update MailDataTest default-id assertions to match delegated id generation

Why

System.currentTimeMillis() can collide during bulk/broadcast mail creation in the same millisecond, causing duplicate primary keys in relational storage or overwrite risk in JSON storage.

Test Plan

• mvn -B -Dtest=MailDataTest test — BUILD SUCCESS, 57 tests, 0 failures, 0 errors
• mvn -B package — BUILD SUCCESS, 459 tests, 0 failures, 0 errors, 11 skipped

Scope

• UltiMail source/test only
• No POM, workflow, schema, migration, release, or deploy changes

Summary by CodeRabbit

• Tests

  • Updated test expectations for ID initialization behavior of mail items, verifying that new instances maintain null IDs before insertion.

• Refactor

  • Modified ID initialization logic in the mail entity constructor to no longer auto-generate values on instantiation.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 3ee2d0b2-42c1-4267-875f-6cb6b3436a56

📥 Commits

Reviewing files that changed from the base of the PR and between 883db24 and 56fa359.

📒 Files selected for processing (2)

• src/main/java/com/ultikits/plugins/mail/entity/MailData.java
• src/test/java/com/ultikits/plugins/mail/entity/MailDataTest.java

💤 Files with no reviewable changes (1)

• src/main/java/com/ultikits/plugins/mail/entity/MailData.java

---

📝 Walkthrough

Walkthrough

MailData's public no-arg constructor no longer auto-generates an id from a timestamp. The constructor continues to initialize sentTime and reset status flags. Corresponding tests are updated to assert that new instances have null IDs rather than auto-generated values.

Changes

ID initialization refactor

Layer / File(s)	Summary
Remove auto-generated ID from constructor src/main/java/com/ultikits/plugins/mail/entity/MailData.java, src/test/java/com/ultikits/plugins/mail/entity/MailDataTest.java	MailData constructor no longer assigns ID via timestamp. Tests updated to verify new instances have null IDs, confirming ID assignment is deferred to persistence layer.

Estimated Code Review Effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 A timestamp was living in a constructor's nest,
Until the day it left to let persistence do the rest,
Now MailData waits for ID to arrive,
When stored, it shall truly thrive!

🚥 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
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'fix: delegate MailData id generation to framework' directly and clearly summarizes the main change: removing timestamp-based ID generation from MailData and delegating it to the framework.
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.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/maildata-id-generation

---

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.}