microsoftgraph / msgraph-metadata

Microsoft Graph metadata captured and used for generating client library code files.
https://graph.microsoft.com
MIT License
107 stars 33 forks source link

`msgraph-sdk-python` expects a response from `/drives/{drive-id}/items/{driveItem-id}/copy` #659

Open aberezh opened 4 months ago

aberezh commented 4 months ago

This issue is created as a follow-up to this pull request.

In msgraph-sdk-python the CopyRequestBuilder (that uses /drives/{drive-id}/items/{driveItem-id}/copy API endpoint) on POST is expecting a DriveItem as a response from Microsoft Graph, while the driveitem_copy REST API doesn't return anything. The code change that I suggested in the pull request mentioned above fixes the problem. But it affects the auto-generated code, so I was asked to create this issue.

More info can also be found in this issue on msgraph-sdk-python.

baywet commented 4 months ago

Thanks for creating the issue.

For context this is the action we're talking about

<Action Name="copy" IsBound="true">
        <Parameter Name="bindingParameter" Type="graph.driveItem" />
        <Parameter Name="name" Type="Edm.String" Unicode="false" />
        <Parameter Name="parentReference" Type="graph.itemReference" />
        <ReturnType Type="graph.driveItem" />
        <Annotation Term="Org.OData.Capabilities.V1.InsertRestrictions">
          <Record>
            <PropertyValue Property="Description" String="driveItem: copy" />
            <PropertyValue Property="LongDescription" String="Asynchronously creates a copy of an driveItem (including any children), under a new parent item or with a new name." />
          </Record>
        </Annotation>
        <Annotation Term="Org.OData.Core.V1.Links">
          <Collection>
            <Record>
              <PropertyValue Property="rel" String="https://graph.microsoft.com/rels/docs/action" />
              <PropertyValue Property="href" String="https://learn.microsoft.com/graph/api/driveitem-copy?view=graph-rest-1.0" />
            </Record>
          </Collection>
        </Annotation>
      </Action>

We could make an XSLT entry so the type changes to void instead, but I'd like for us to confirm with the workload this is effectively the case before we do so. (meaning, it's always LRO pattern and will NEVER return a payload)

dianalingtung commented 1 week ago

Hi,

Could you provide an update on the status of this request? I am also dealing with the same issue and would like to see this issue resolved.

Thank you,

Diana

baywet commented 2 days ago

Thanks for the nudge, this fell through the cracks.

@irvinesunday LRO pattern is not clear on guidance as far as I could tell on whether the return type should be:

For this reason I don't think opening a service issue on the service team will get us far here. I suggest we instead add a new entry to the transform to remove the return type here. Thoughts?