I’ve just upgraded FME Flow to v2023.2 Build 23774. One of my users found that they were not getting any results for a workbench that was working before the upgrade and had been run by others users, including themselves, after the upgrade.
In researching this particular case I found that the user was had uploaded a file as an input for the workbench, that was the same as an existing uploaded file, however in this case the naming of the files were the same except that one had the filename in all UPPER case, while the other filename was in a mix of UPPER and LOWER case. Upon running the workbench the user is not made aware that the upload of the file has in fact failed (the original version on Flow is maintained as it was) but sees that the workbench has failed with an error indicating the file could not be located. Has anyone else seen this or can replicate it.
It seems like there is a different set of rules in place for uploading files as opposed to reading files. The reading of files by the workbench seems more specific and takes into account the case of the characters in the filename when looking for the resource. When uploading it does not take this into consideration and prevents the latest file version from being uploaded to the Flow. I think the same rules should apply to both tasks.
I had the same issues with FME Flow 2022 but that was even more difficult as any file re-uploaded did not overwrite the existing file on Flow, so in that case I had to set the Delete Upload Files period to every 5 minutes to reduce the possibility of issues arising from that. I also read the localhost_access-log files looking for an instances of this error occurring, automating the sending of an email to the user indicating their outputs from the workbench may contain errors.
I hope this problem is restricted to just the case noted above and not something having more widescale effects.
IDEA: Is there a way to allow users to see the files they have already uploaded onto the server for a given workbench and possibly remove those they do not want any longer? This might trigger a one-off scheduled task request on Flow to remove the specific file(s) and avoid giving the users permissions to do it themselves?