It is possible to have an entry in the files table with a 'referencefileid' that points to itself. I believe this is not valid data but it can happen in real systems. I don't know how it gets set up that way but I know it is possible for two reasons:

1. It did in one of ours.
2. There is code in send_stored_file function that detects the situation and sends 'Recursive file serving detected' coding exception to users.

Generally this does not cause many problems, I mean obviously the file doesn't work (see above error) but other than that.

However, if a file like this is included in an area that is indexed by the Solr search engine (or probably another search engine that supports indexing files), then the search indexing task crashes out, and not in a nice way - instead of throwing an exception with message that could let an administrator resolve the problem, it dies with a PHP stack overflow, causing the shutdown functions not to be called and the task to appear as if it is still running. Eventually, the task will be detected as failed because its database lock has been removed, and it will be marked with a fail delay and will retry (and fail again the same way, etc), but there will be no log entry for the fail run.

I am not sure if search indexing is the only area affected by this, it might be, but in summary, causing a PHP stack overflow is best avoided.

After debugging I have discovered that the problem occurs in stored_file::sync_external_file function, which (later in repository::sync_reference function) calls get_contenthash on the file, which calls sync_external_file again, which etc.

I propose resolving the problem by making it throw a coding exception, similar to behaviour in send_stored_file, including the file id to make it easier to resolve it.