GetFileByServerRelativeUrl fails with nondescriptive error on files with only one version

[tomacPA]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

SharePoint REST API

Developer environment

Windows

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

Calling the SP API via the Power Automate action "Send an HTTP request to SharePoint"

Describe the bug / error

Using the following URI:
https://tenant.sharepoint.com/teams/LibraryName/_api/web/GetFileByServerRelativeUrl('/teams/LibraryName/Shared%20Documents/General/TestFile.txt')/versions(512)/$value

The API call fails with the following error:
"body": { "status": 400, "message": "Cannot write the value 'null' in raw format.\r\nclientRequestId: 69c173cf-acca-422b-9f3a-79a83616ddb7\r\nserviceRequestId: 099cd1a1-10af-a000-801f-818442e1a307", "source": "https://tenant.sharepoint.com/teams/LibraryName/_api/web/GetFileByServerRelativeUrl('/teams/LibraryName/Shared%20Documents/General/TestFile.txt')/versions(512)/$value", "errors": [ "-1", "Microsoft.Data.OData.ODataException" ] }

This failure only occurs on files that do not have multiple versions, in other words where the version in the library is the original upload. It works as expected in the same folder for files with multiple versions.

When running automation to gather v1.0 files in a directory, the API will work on files with multiple versions and fail on files where v1.0 is the only version.

Steps to reproduce

1. Have a SP directory with files that have multiple versions and files that are the original upload with no subsequent versions
2. Run a script that gathers a list of the files in the directory, then loops through each file calling this API to get v1.0 of each file
3. Observe returned values from API calls are failures for files without multiple versions

Expected behavior

Expected behavior would be to return file content for all v1.0 files even if v1.0 is the only version.

[Ashlesha-MSFT]

Hello @tomacPA,
Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.
If you don’t receive a reply within two working days, please use this escalation form to escalate.

[Amey-MSFT]

Hello @tomacPA,
Could you please help confirm a few details so we can better analyze the issue?

• Does this behavior occur for all files that have only one version, or just specific ones (for example: certain file types, or libraries with specific settings)?
• Is versioning definitely enabled in the target document library?

Thank you!

[tomacPA]

Hi Amey, thanks for following up.

Here are the versioning settings for this document library:

I tried with the following filetypes:
XLSX, DOCX, TXT, PDF, BMP, GIF, PNG, JPG

I also tried newly uploaded files with immediate edits and files that have been in place for over a year with and without edits.

Results were consistent regardless of file type or age, the only differentiator was whether the file had multiple versions or not.

[Amey-MSFT]

Hello @tomacPA,
We were able to reproduce the issue, and we are investigating it. We have logged this as a bug, and our engineering team will look into it.
Thank you!

[jansenbe]

Hi @tomacPA : when you want to get the latest version of a file you do not need to go via versions endpoint, just pull down the latest version of the file (e.g. _api/web/getFileByServerRelativePath(decodedUrl='%5Csites%5Cprov-1%5Cgraph%5CDocument.docx')/$value)...in this case the latest version is also the first version as there's only 1. You can call _api/web/getFileByServerRelativePath(decodedUrl='%5Csites%5Cprov-1%5Cgraph%5Cdocument.docx')/versions to understand if there's versions, and if so use _api/web/getFileByServerRelativePath(decodedUrl='%5Csites%5Cprov-1%5Cgraph%5Cdocument.docx')/versions(512)/$value the first version of the file

[tomacPA]

Hi @jansenbe

This issue came up in a discussion of a method to gather v1 of all files in a directory to take action on those v1 files. The bug was encountered when a directory contains a mix of files that have multiple versions and files that do not.

Given the licensing model of Power Automate, running additional API calls to check if a file has additional versions or not could incur additional costs. I expect the API in use should be able to return v1 of a file regardless of whether there are additional versions or not, since all files in SharePoint will have at minimum a v1