Hi All!
We are running into a similar issue as this one. I would like to find out a list of our file resources to see which one is problematic or missing. The developer documentation only provides guidance of sending POST requests or GET requests for specific resources to the /api/fileResources route.
How can I determine which file resource is problematic?
Thanks!
Hi @jniles
There is no way to retrieve this information from the api. The reason is that we donāt want to leak information about files/data that might be sensitive.
The issue in the other topic you are referring to, is a bug from our side, which we will address if it havenāt been already. This issue occurs when DHIS2 initiates a cleanup task, removing any failed or orphaned files, and should not affect your normal DHIS2 interaction, with the exception of polluting the logs.
If you wish to do you own research on the FileResources, my advice would be to go through the database. The āfileresourceā table contains all the FileResources created in DHIS2, including references to the actual files it represents. This table, however, does not link to the metadata it is used by. For example DataElement values and Attribute values reference FileResources by setting their value to the UID of the FileResource. Other metadata, like Document and message attachments have foreign keys pointing to the FileResource. In other words, trying to dig up all of this can be a complex task.
To address your question about how to determine which file resources are problematic, you need to know what triggers the problem:
When we try to delete a FileResource which is referenced by other data that we have not cleaned up, we get the error described in the other topic. The FileResources we try to delete are orphaned files that are older than a fixed amount of time. Orphaned FileResources are indicated in the database in rows where
the āassignedā column is āfalseā. Additionally, before we try to delete the FileResource, we also make sure that the File it represent is in fact not successfully uploaded. If the File actually exist, we update the assigned column to ātrueā and wont delete it.
In other words, old FileResources that are āassigned=falseā, does not have a file uploaded and is referenced by metadata we fail to clean up is how you can determine the problematic FileResources. The easiest way to deal with this in other words is to report any issues like this to us, so we can fix these bugs and the cleanup should work without a problem.
I hope this explanation helped you!
Hi @Stian,
Thanks for your detailed explanation. We have been trying to track down an analytics bug and this was one line of inquiry. From your explanation, it seems like this shouldnāt be related.
Thanks so much!