-
Notifications
You must be signed in to change notification settings - Fork 18
CUST-4111/CUST-4162: improve to more descriptive error response & validate event's start vs end time #300
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
This PR will cover two tickets: https://nylas.atlassian.net/browse/CUST-4162 → automatically also more descriptive error response when API error response cannot be parsed |
This comment was marked as resolved.
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) { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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>
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.