Panic while uploading certain item attachments

[HiteshRepo]

We encounter panic: were unable to deserialize while trying to upload attchements using below API:

client.
Users().
ByUserId(userID).
MailFolders().
ByMailFolderId(containerID).
Messages().
ByMessageId(parentItemID).
Attachments().
Post(ctx, body, nil)

client is of type *msgraphsdkgo.GraphServiceClient.

Below are couple of sample item attachement jsons for which we get the above panics:

• non-nested item attachment
• nested with event inner attachment

However we do not get the issue for below: non-nested item attachment #2

Please advise us in case there is something wrong with the structure/content of the item attachement jsons that is leading to the panic. Or is there is any issue with any of the below libs:

• https://github.com/microsoftgraph/msgraph-sdk-go
• https://github.com/microsoft/kiota-serialization-json-go

In either case we should not be getting panics rather some appropriate error message.

[saviorand]

@andrueastman @rkodev @baywet any update on this? We are getting a panic where e.g a "dimensions" property on a File in a Drive of type Photo is a string, and not a float.

Based on this discussion in kiota-serialization-go https://github.com/microsoft/kiota-serialization-json-go/issues/142 , this is intended behaviour by kiota but not handled properly by msgraph-sdk-go. This then causes a panic that prevents the user from retrieving any files of the graph SDK.

Should I create a separate issue for this?

[michaeldcanady]

@saviorand Would you be able to provide the JSON you’re passing in and how are you generating the JSON?

[michaeldcanady]

Apologies I see your examples. Can you verify your version of the JSON serializer is the latest and where you able to pinpoint what key is causing the issue? After a cursory glance I don’t see any that appear like the expected error case I outlined.

[andrueastman]

@saviorand As suggested by @michaeldcanady, Any chance you can confirm this is happening if you have the latest version of the sdk?

[saviorand]

@michaeldcanady @andrueastman I am on [email protected];

just tried running it again, I'm getting errors:CLIENT_FAILURE: failed to get drive items: *errors.errorString > error: &errors.errorString{s:"value '1' is not compatible with type int32"}

when I run this in the debugger, the error is thrown here: /go/pkg/mod/github.com/microsoftgraph/[email protected]/models/photo.go. I marked with a comment the exact spot where the error is thrown:

res["orientation"] = func (n (omitted).ParseNode) error {  
    val, err := n.GetInt32Value()  
    if err != nil {  // value '1' is not compatible with type int32
        return err  
    }  
    if val != nil {  
        m.SetOrientation(val)  
    }  
    return nil  
}

Is this not the latest version? I think I just did go get https://github.com/microsoftgraph/msgraph-sdk-go@main

[saviorand]

Here is the file (photo) I'm using if it's helpful, but I'm sure the issue can be reproduced with any file that has a string representation of an integer in the "orientation" field

[michaeldcanady]

@saviorand what version of the JSON serializer are you using? My fix wasn’t released until 1.0.8.

[saviorand]

@michaeldcanady I am just calling msgraph-sdk-go , kiota-serialization is an indirect dependency for me. Looks like it's at 1.0.8 in my go.mod

[baywet]

@andrueastman this is related to #685, the workload (OSDP) updated the service to return ints. We should open an ICM on this workload (Exchange) so they also fix their API to return ints.

[saviorand]

@baywet am I right to assume this might take a while for that team to get back with a fix? Based on the discussion in the other issue.

[baywet]

@saviorand yes, even when the teams are reactive and prioritize the work, the deployment takes weeks.

[andrueastman]

@saviorand Any chance you can confirm the api you are calling in this scenario? The orientation property seems to be from photo model. https://github.com/microsoftgraph/msgraph-sdk-go/blob/bd43bef66082d28fb8383ac50ccdcbdac82a3d1c/models/photo.go#L176

However the original issue was calling the attachments api as below.

client.
Users().
ByUserId(userID).
MailFolders().
ByMailFolderId(containerID).
Messages().
ByMessageId(parentItemID).
Attachments().
Post(ctx, body, nil)

We may need to follow up with the ODSP team again about this depending on which API is being called.

[saviorand]

@andrueastman @baywet yup it's in the Photo model, and this is the call I'm making where it panics, so the Drive API driveItemsResult, err := client.Drives().ByDriveId(driveID).Items().ByDriveItemId(itemToSearch).Children().Get( ctx, nil )

[andrueastman]

Thanks for the info @saviorand

Looks to be the exact scenario as https://github.com/microsoftgraph/msgraph-sdk-go/issues/685.

Following up with the relevant team at https://portal.microsofticm.com/imp/v5/incidents/details/544783286/summary and will give feedback once we get confirmation on the current state of things here.

[saviorand]

@andrueastman thanks a lot!

[buechele]

@andrueastman @baywet @michaeldcanady Is there any update on this issue? I'm getting the error (not a panic) value '1' is not compatible with type int32 as a result from calling results, err := graphClient.Drives().ByDriveId(driveID).Items().ByDriveItemId(driveItemID).Delta().GetAsDeltaGetResponse(context.Background(), nil)

Calling on the same driveID and driveItemID results, err := graphClient.Drives().ByDriveId(driveID).Items().ByDriveItemId(driveItemID).Children().Get(context.Background(), nil) works without issues.

Is there any fix or workaround for this?

[buechele]

@andrueastman @baywet @michaeldcanady I have just discovered that it seems to work in msgraph-beta-sdk-go v0.120.0.

[baywet]

@buechele thanks for the nudge on this one.

The conclusion of this (and the previous) incident we opened on the service team is the service was NOT sending the correct data type back, and a fix was implemented at the service level.

There might still be differences between the beta and v1 versions of the service at the time being, which would explain why you're seeing a difference.

In any case, as the client experiences team we do not have access to backend services. Please contact the support. More information

Closing