Skip to content

Conversation

@googsvg
Copy link

@googsvg googsvg commented Jan 21, 2026

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.

@googsvg googsvg requested a review from AaronDDM January 21, 2026 16:36
@googsvg googsvg changed the title CUST-4111: improve to more descriptive error response & validate event end vs start time CUST-4111: improve to more descriptive error response & validate event's start vs end time Jan 21, 2026
@googsvg
Copy link
Author

googsvg commented Jan 21, 2026

This PR will cover two tickets:
https://nylas.atlassian.net/browse/CUST-4111 → validation of event's start vs end time in create/update, and better error message handling

https://nylas.atlassian.net/browse/CUST-4162 → automatically also more descriptive error response when API error response cannot be parsed

@googsvg googsvg changed the title CUST-4111: improve to more descriptive error response & validate event's start vs end time CUST-4111/CUST-4162: improve to more descriptive error response & validate event's start vs end time Jan 21, 2026
@codecov-commenter

This comment was marked as resolved.

fun build() = Timespan(startTime, endTime, startTimezone, endTimezone)
fun build(): Timespan {
// Validate that endTime must be after startTime
require(endTime > startTime) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, this is a breaking change. If we introduce this, then customers had to now handle the new exception thrown. I'd avoid it unless you plan on doing a major release, or make it backwards compatible

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but that is the whole problem of the ticket, the customer was sending the identical start and end date instead of using the when-time event

// Local variables for smart-cast null safety
val start = startTime
val end = endTime
if (start != null && end != null) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same about this being a breaking change

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same answer as for create

* Request ID: abc-123
* ```
*/
override fun toString(): String {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the current value prior to this override?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Claude says previously with no customized "toString":

NylasApiError(message=Bad Request, statusCode=400, requestId=abc-123, ...)

and now:

NylasApiError: Bad Request (HTTP 400)
Validation errors:
  - when.end_time: must be after start_time
Request ID: abc-123

for me it is a better experience, but I'm new to this SDK - so.... :)

Add test case for the scenario where API returns valid JSON but
the error object parses to null, triggering the final fallback
error message path in NylasClient.

This improves test coverage for the enhanced error handling
introduced in the previous commit.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
@googsvg googsvg requested a review from AaronDDM January 21, 2026 16:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants