Excel retry options should work with 'file locked' error 423 condition

[MattC_A]

We have a simple flow that is inserting data into an Excel spreadsheet in OneDrive.. it works great until I'm looking at the file & then Flows error with, 423 - File locked, e.g.

If you look in the Settings for the 'Insert Row' step, they look like they should handle this nicely, by retrying over a specified period of time, e.g.

But unfortunately they don't have any effect.. the operation isn't retried at all & the Flow fails.

This really needs fixing.

[cmalone]

This simple retry solution would significantly improve interactions with Flow + Excel.  Obviously the better solution would be to fix the underlying lock stick that is going on here, or alternately provide Admin access to kill locks for a specific file, but I'll take what I can get.

[JorgeCarvalho]

+1

Being able to specify which errors trigger the retry, instead of working with a predetermined list, would be a major improvement.

File locks, when updating metadata for open documents is a significant source of problems for us.  

[Anonymous]

I'm experiencing siimilar issue with "Update file properties" Flow action. The Retry Policy seems not doing anything and fails without a retry. My issue is with the file being locked "is locked for shared use by" error. I'm simply trying to tell Flow action to retry on a failure xx times with PT15M

[jbedfordp]

+1 for me, too

I created a flow which attempts to assign an identifier to certain types of documents when they are created in a SharePoint library. The error I get is a '"status": 400' error -- file is locked for shared use.

I'm guessing this is because when certain file types are created in a SharePoint library (like Word docs), the file is automatically opened for editing immediately upon creation. So when Flow detects the file was created, it is not able to modify the SharePoint library column.

This is strange, though... my Flow does not attempt to modify the file itself, but rather only attempts to add metadata to the library record associated with the file. Why should doing this require the file itself to be unlocked? I could understand this happening if the Flow was attempting to modify the contents of the file, or perhaps the filename... but associated metadata? Seems like overkill locking.

[jbedfordp]

I was able to (painfully) work around this by adding additional rudimentary error handling within a "Do Until" loop:

I initialized a new variable "SuccessfulUpdate" set to 'false', and only exit the loop when it is set to 'true'.

The SharePoint "Update file properties" has parallel branch output that does a "Delay" if it fails, and sets the SuccessfulUpdate variable to 'true' if it succeeds.

In production I'd probably change the Delay to be significantly longer than 1 minute for my use case, but for testing this works well enough. 

For context...

... my Flow attempts to assign an sequential numerical identifier to a file in a SharePoint library when it is created, based on determining the max existing identifier in that library. This is probably something that should be possible OOTB on SharePoint, but that's another issue. My issue is that, when creating a file in SharePoint, the file is automatically opened for editing upon creation, and that puts a lock on the file that prevents Flow from updating the record in the library.

A variety of things would have prevented needing this workaround:

- If SharePoint could auto-assign identifiers upon file creation using minimally custom criteria (i.e., only assign numbers to files of a certain type).

- If Flow did not require the kind of lock that it seems to require in order to update a file's metadata.

- If Flow's OOTB error handling could handle errors related to locked files.

- If SharePoint didn't open files for editing by default upon creation.

Sigh.