microsoftgraph / msgraph-sdk-java-core

Microsoft Graph SDK for Java - Core Library

Home Page:https://docs.microsoft.com/en-us/graph/sdks/sdks-overview

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Inconsistency with GraphError's code property and GraphErrorCodes.ITEM_NOT_FOUND

GeertZijlmans1 opened this issue · comments

Expected behavior

When a GraphError's code field has the value "ErrorItemNotFound", then GrapError#isError method should return true for GraphErrorCodes.ITEM_NOT_FOUND.

Actual behavior

I have a catch-block for a GraphServiceException and I'm checking the error code that is returned. This check uses GraphError#isError. For GraphErrorCodes.ITEM_NOT_FOUND this check returns false, whereas the log shows:

CoreHttpProvider[sendRequestInternal] - 408Graph service exception
Throwable detail: com.microsoft.graph.http.GraphServiceException: Error code: ErrorItemNotFound
Error message: The specified object was not found in the store.

Steps to reproduce the behavior

  1. Create code similar to the code below and verify that for a non-existing Event ID it will return a GraphServiceException with code "ErrorItemNotFound", yet it will not log the line as stated in the exception.

`
try
{
graphServiceClient.users(resourceIdentifier) //
.events(eventId)//
.decline(EventDeclineParameterSet.newBuilder().withSendResponse(false).build())
.buildRequest()//
.post();

       // Decline it twice to get the ErrorItemNotFound exception
       graphServiceClient.users(resourceIdentifier) //
            .events(eventId)//
            .decline(EventDeclineParameterSet.newBuilder().withSendResponse(false).build())
            .buildRequest()//
            .post();
        
        LOG.info(String.format("Declined event for ID <%s> for Resource <%s>", eventId, resourceIdentifier), aContext);
    }
    catch (GraphServiceException aException)
    {
        // Item not found so nothing to decline, proceed as if it was a success
        if (aException.getServiceError().isError(GraphErrorCodes.ITEM_NOT_FOUND))
        {
             LOG.info(String.format("No need to decline event for ID <%s> for Resource <%s> as it was already not present", eventId, resourceIdentifier), aContext);
        }
    }

`

Expected solution

Expected problem is the comparison made in GraphError#transformErrorCodeCase

Where "ErrorItemNotFound" is compared to ITEM_NOT_FOUND, this yields false as either the code should have been "ItemNotFound" or GraphErrorCodes.ERROR_ITEM_NOT_FOUND should have existed.

Hi @GeertZijlmans1 , I believe you are correct. It seems that there may have been a change to an error code or error code update that may not have been accounted for. According to the documentation here: https://docs.microsoft.com/en-us/graph/errors, we should be expecting the response code to read ItemNotFound, however, testing in GraphExplorer does show instances 'ErrorItemNotFound', which is not in line with the documentation. I will investigate if this is a graph wide change or if this is specific to the Events API and will update you on what the best course of action would be for your scenario.

@ramsessanchez

I also encountered that I received a ValidationError on trying to patch one of my subscriptions. This error is not documented on the page you provided (and not present in the GraphErrorCodes enum).

com.microsoft.graph.http.GraphServiceException: Error code: ValidationError
Error message: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server.

PATCH https://graph.microsoft.com/v1.0/subscriptions/05db9d15-cab0-4a0b-8063-5c572812bd1d
SdkVersion : graph-java/v5.33.0
[...]

400 : Bad Request
[...]

[Some information was truncated for brevity, enable debug logging for more details]
at com.microsoft.graph.http.GraphServiceException.createFromResponse(GraphServiceException.java:419)
at com.microsoft.graph.http.GraphServiceException.createFromResponse(GraphServiceException.java:378)
at com.microsoft.graph.http.CoreHttpProvider.handleErrorResponse(CoreHttpProvider.java:512)
at com.microsoft.graph.http.CoreHttpProvider.processResponse(CoreHttpProvider.java:442)
at com.microsoft.graph.http.CoreHttpProvider.sendRequestInternal(CoreHttpProvider.java:408)
at com.microsoft.graph.http.CoreHttpProvider.send(CoreHttpProvider.java:225)
at com.microsoft.graph.http.CoreHttpProvider.send(CoreHttpProvider.java:202)
at com.microsoft.graph.http.BaseRequest.send(BaseRequest.java:335)
at com.microsoft.graph.requests.SubscriptionRequest.patch(SubscriptionRequest.java:99)

Hi @GeertZijlmans1, I believe that the ValidationError is not a graph specific error thus the reason why it is not a part of the enum set that was mentioned earlier.
In regards to your previous issue, we have noticed that the error code is specific to the Microsoft Exchange workload. It is most likely that we will look into adding ErrorItemNotFound to the enum set as it is unlikely that they will change the error code on their end. Thanks for your patience.

@ramsessanchez

Thanks for your reply. But as it seems the errors mentioned are being wrapped into a GraphServiceException given the logging, hence one would expect these type or errors being part of the enum.

So the "ErrorItemNotFound" seems to occur when the workload on Exchange is too high, which would be more like something "don't bother us right now" / "Service too busy". Is there any strategy other than performing a retry in an exponential back off such that Exchange will be able to respond to our request?

Gladly awaiting your insights

@GeertZijlmans1
Apologies for the delay, but we have determined that the current best course of action is to include that error code in our enum set. We are currently working on a new version of our SDK which will include improvements to both our service library as well as the core library which we expect will prevent issues such as this to happen in the future. Thanks for helping us improve!

@ramsessanchez
Thanks for acknowledging the issue and thanks for the improvement in the SDK. Is there any chance that this ErrorItemNotFound turns into a 'Service too busy' kind of error with an exponential back off? As you stated in one of your comments this error gets thrown when the workload is high on an Exchange environment.
Also could this error occur more often when using a hybrid setup in O365? As we have noticed this error occurring more often when customers still have an on-premise Exchange environment.

@GeertZijlmans1 , the latest version of the v1 sdk uses GraphCore 2.0.14 which includes the added enum. microsoftgraph/msgraph-sdk-java#1233
As for your earlier question, I am not certain as I am not familiar with the Exchange workload or their exception handling unfortunately.