[Bug]: InputDataAgent always uses FileCatalogClient

[maxnoe]

Search before creating an issue

• I have searched existing issues and confirmed this is not a duplicate

Bug Description

The InputDataAgent directly instantiates the FileCatalogClient instead of going through FileCatalog, making it impossible to use the InputDataAgent when the main file catalog of a DIRAC deployment is a RucioFileCatalog.

Steps to Reproduce

DIRAC/src/DIRAC/TransformationSystem/Agent/InputDataAgent.py

Line 48 in 36806a1

self.metadataClient = FileCatalogClient()

Expected Behavior

Use FileCatalog to obtain the correct client for the current configuration.

Actual Behavior

No response

Environment

No response

Relevant Log Output

Additional Context

No response

[maxnoe]

Codex made the following observations on replacing FileCatalogClient with FileCatalog, I don't know the code base and the inteded behaviors well enough to judge the merits of this analysis:

Switching InputDataAgent from FileCatalogClient to FileCatalog is consistent with configured-catalog usage, but it is not semantically
identical in MultiVO mode.

Previously, the code used:

FileCatalogClient(
    useCertificates=True,
    delegatedDN=transDict["AuthorDN"],
    delegatedGroup=transDict["AuthorGroup"],
)

That meant the standard FileCatalog service call was made using delegated user credentials from the transformation author.

The new pattern uses:

FileCatalog(vo=getVOForGroup(transDict["AuthorGroup"]))

That selects the VO-specific configured catalog stack, which is what enables deployments where the main catalog is RucioFileCatalog. This
matches patterns elsewhere in DIRAC, such as FileCatalog(vo=vo), DataManager(vo=...), and StorageElement(vo=...).

The caveat is that FileCatalog does not accept delegatedDN / delegatedGroup, so the delegated identity is no longer preserved in the same
way. It selects the VO configuration, not the author’s delegated credentials.

So the summary was:

• Single-VO behavior is consistent and should be effectively unchanged if the configured catalog resolves to the normal DataManagement/
  FileCatalog.

• Multi-VO behavior is consistent with DIRAC’s configured-catalog dispatcher style.

• But it changes semantics compared to the old delegated FileCatalogClient path.

• This is probably the right direction for Rucio-backed catalogs, but the regression risk is standard DFC-only multi-VO setups that relied
  on delegated author credentials.