Felix A. Croes

The `msiModAVUMetadata` microservice was called from the iRODS rule set on the ICAT machine.

> Sorry, I'll rephrase the questions. > > Q. What client-side tool did you use? Q. Is the client-side tool connecting to the provider or a consumer? _(this is very...

> @dworkin - Also, just to be clear, since this issue is in irods/irods instead of [http://github.com/irods/irods_capability_indexing](https://github.com/irods/irods_capability_indexing), what is the "desired side effect"? a) the creation of an AVU on...

I can confirm that the following does work: ``` remote("localhost", "null") { msiModAVUMetadata("-C", *collection, "add", "irods::indexing::index", "yoda::metadata", "elasticsearch"); } ```

Unfortunately, using remote() runs headlong into issue #6286, causing log spam and occasional crashes. The INST_NAME tag doesn't appear to be recognized by remote().

@d-w-moore I suspect that my setup is different: `server_config.json` has plugins for iRODS rule language, Python and elasticsearch indexing. What I see is that the rule code is executed by...

iRODS 4.2.11, Centos 7.9

@korydraughn Yes I did. The problem does not occur in how `irule` executes the rule, but in how the rule executes the remote section.

My assumption that `default_resource_name` should not be at the top level turns out to be incorrect. However, on line 147 of `setup_irods.py` it is assumed to be present in `server_config`.

[This code](https://github.com/irods/irods/blob/e8607090d1ef3a47b8ccd7478d783d6a4e7d3a8e/server/api/src/rsFileClose.cpp#L93-L100) tries to deal with an earlier version of this problem and may be superfluous after the pull request is merged, assuming that it really only deals with the...