Repository navigation
Error Handling #1785
Description
Activity
Exactly same exception here when i am trying to download a file:
graphClient.drives().byDriveId("XXXXXXXXXXXXX")
.items().byDriveItemId("root:/MediaMeta.xml").content().get()Failure happens during deserialization of the
innerError'sdateproperty. The API returns a date time string without the offset e.g. "2024-02-12T19:47:39" but our OpenAPI spec expects a DateTime with an offset which maps to the SDK expecting DateTimeOffset objects. The parsing failure is valid..NET's DateTimeOffset implementation seems to handle this case by defaulting to using the UTC timezone. Java's fails.
Vincent Biret (@baywet) Andrew Omondi (@andrueastman) might this be an issue during our metadata conversion?
Kiota maps the
format: date-timeto DateTimeOffset which downstream languages change in the refiners. Which looks like the right thing to do.However, the pattern string/regex suggest that the offset is optional despite the OpenApi spec defining the offset as mandatory for
date-time. This is probably because odata ABNF has the the offset as optional.date: pattern: '^[0-9]{4,}-(0[1-9]|1[012])-(0[1-9]|[12][0-9]|3[01])T([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9]([.][0-9]{1,12})?(Z|[+-][0-9][0-9]:[0-9][0-9])$' type: string description: Date when the error occured. format: date-time nullable: true
Ideally,
- The conversion lib should drop
format: date-timeforEdm.DateTimeOffsettypes and generate only a string pattern. - Kiota should pick up the pattern then use it to map to the
DateTimeOffsettype(since the offset can be there)
However, since it would it still end up being to the
DateTimeOffsettype, I think we probably would end need to end up just updating the deserialization library to allow for the scenario and default to UTC.Reacted by Vincent Biret- The conversion lib should drop
Thank for the clarity Andrew Omondi (@andrueastman)! I agree that we can add a default UTC offset if none is present in the API response before deserializing to a DateTimeOffset.
Exactly what Andrew said. Just adding a bit of tolerance when parsing things here should be enough.
It's interesting that Java is the only language with which we've faced that to date though, but it makes sense since Java "is more of a purist language".Reacted by Andrew OmondiVersion
6.2.1contains this fix.
Expected behavior
The message of the ApiException will contain a more specific error message based on the OdataError returned from the API.
Documentation
Actual behavior
When trying to get user who does not exist in Graph java.time.format.DateTimeParseException is thrown
Steps to reproduce the behavior
Result:
Library: