I was right about my suspicion. I was able to fix the problem and verify the solution on Meridian 2016 and 19.0.0:

https://github.com/OpenNMS/opennms/pull/1175

I have a hunch about why this is happening.

Comparing the logs between Meridian 2015 and Meridian 2016, you can see that the new DirectoryWatcher and the updated FasterFilesystemForeignSourceRepository are being used only on Meridian 2016 (and of course newer versions of Horizon).

In order to properly support org.opennms.provisiond.repositoryImplementation=fastFile, this updated FS repository uses the internal cache maintained by the watcher as the "source" for requisitions during the import phase. This is true and valid only for local requisitions as the directory watcher guarantees this.

For external resources (like requisitions hosted on different servers as PRIS), this is not true, and the repository should falls back to the "old" behavior instead. This "old" behavior is actually what Meridian 2015 is executing. In fact, this explains why the "old" content of the requisition is used (because this is actually what the cache contains, and that's why the first time it works).

For this reason, the fix seems to force the usage of this cache if and only if the resource is associated with a physical file, and not when it is associated with a remote requisition when performing an import operation. I'm going to build a test environment to verify this hypothesis.

I found something interesting:

On Meridian 2015, I've recreated the same test scenario I've used for Meridian 2016, but this time the scheduler works as expected with HTTP sources (and I bet it works as well with DNS, VMWare, etc.). That means, the problem is something recent (or at least post-Meridian2015).

The FileNotFound exception is logged on Meridian 2015 (as a DEBUG, not as an ERROR), and the stack trace is the same (of course with different versions of the libraries involved). The difference is, Provisiond is actually updating the requisitions and the inventory properly on 2015, but not on newer versions.

Here is a problem that I found:

I modified the source requisition to change the node label for one node, and remove another node, and after Provisiond requested the import again through HTTP, the changes were not applied as expected. This is definitively a problem.

Also, I found that error on the logs happens only the first time the requisition is imported. On subsequents imports, the exception happens but it is not reported as an error: