CUST-3867 changed SendMessageRequest.sendAt to Long

[samuelpx]

Added a method overload that converts passed ints to Longs, so that the change is not breaking. There should be a warning thrown if Kotlin users pass int literals, but these can be ignored/corrected easily (and should not be happening anyway). Tested this thoroughly.

License

I confirm that this contribution is made under the terms of the MIT license and that I have the authority necessary to make this contribution on behalf of its copyright owner.

[playerzero-ai]

Pull Request Summary

• Functionality Changes:

  • The sendAt field in the SendMessageRequest class has been changed from Int to Long. This change allows the system to handle larger timestamp values, accommodating future dates beyond the Int.MAX_VALUE.
  • The builder class for SendMessageRequest has been updated to accept Long values directly for the sendAt field, aligning with the main class change.

• User Experience Improvements:

  • Developers can now input larger timestamp values directly as Long, improving the ease of scheduling messages for future delivery.
  • A new method in the builder class converts Int to Long for the sendAt field, ensuring backward compatibility for existing code that uses integer timestamps.

• Testing Enhancements:

  • Two new test cases have been added to verify the correct handling of sendAt values:
    • One test checks the conversion from Int to Long and ensures the API request is correctly formed.
    • Another test ensures that timestamps beyond Int.MAX_VALUE are processed correctly, validating the system's ability to handle edge cases.

Files Changed

File Name	Summary
src/test/kotlin/com/nylas/resources/MessagesTests.kt	Added two tests for sending messages with sendAt as Int and Long to verify correct handling and API request formation for future scheduling, including edge cases beyond Int.MAX_VALUE.
src/main/kotlin/com/nylas/models/SendMessageRequest.kt	Changed sendAt type from Int to Long in SendMessageRequest and its builder; added builder method to convert Int to Long for backward compatibility and improved timestamp precision.

View more in PlayerZero
updated: Aug 22 @ 11:43 AM UTC

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.75%. Comparing base (7deff22) to head (7c34de6).

Additional details and impacted files

@@            Coverage Diff            @@
##               main     #296   +/-   ##
=========================================
  Coverage     81.75%   81.75%           
  Complexity      344      344           
=========================================
  Files            36       36           
  Lines          1014     1014           
  Branches         88       88           
=========================================
  Hits            829      829           
  Misses          132      132           
  Partials         53       53           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[AaronDDM]

@samuelpx I don't understand why this needs to be a Long. Isn't it a Unix timestamp? What is the issue exactly?

Edit: ah, never mind. I see 2038 dates won't work. Good stuff. Can we apply this elsewhere?

[samuelpx]

Other timestamps in the SDK are already longs I think we're good. Other SDKs don't run into this, Ruby auto-converts, Python's int limit is memory-based, TS's biggest number hits an epoch date of 2255.