Content Repository Pull Process Scaling and Merge Conflict Resolution in Aria Orchestrator

VCF Operations/Automation (formerly VMware Aria Suite)

Aria Orchestrator content-repository pull operations may experience significant performance degradation when large numbers of merge conflicts occur simultaneously.
This article details how the REST API handles merge conflicts, clarifies bulk submission capabilities, and provides best practices for managing large-scale conflict resolutions.

VMware Aria Orchestrator 8.18.x

The /vco/api/content-repositories/requests/pull REST API endpoint requires explicit conflict resolution per rebase step.Because the API lacks built-in "strategy-based" automatic conflict resolution (such as "always accept incoming"), processing large-scale divergent items one at a time creates excessive API round-trip iterations.
This leads to database transaction timeouts and severe performance bottlenecks.

To optimize large-scale content-repository syncs:

Implement Batch Conflict Resolution via API Client
- Update automation scripts to parse the full paths array returned during MERGE_CONFLICT responses and post all resolved items in a single merged-items payload per iteration round.
Perform Git-Level Pre-processing
- Perform upstream Git operations (such as rebasing or squashing commits) prior to initiating the pull request in Aria Orchestrator to reduce multi-step rebase loops.
Increase Database Transaction Timeout
- If large batch processing loops approach timeout limits, increase the database transaction timeout:
  - SSH into the Aria Orchestrator appliance and run:
```
vracli vro properties set -k com.vmware.o11n.db.transaction.timeout -v 1200
```
    Note: Perform a full environment backup before modifying appliance properties.
Repository Reset
- If the local repository state is severely corrupted or unaligned, a full repository reset (re-cloning) may serve as a recovery fallback.

1. Is a Git-level workaround required for a stuck PULL operation (similar to push-side workarounds)?

No. Unlike push operations, a Git-level CLI workaround is not strictly required because the PULL API supports submitting multiple conflict resolutions together per round-trip step rather than restricting execution to single-item resolution.

2. Does /vco/api/content-repositories/requests/pull support bulk or strategy-based conflict resolution?

Bulk Submission: Yes. The request body (WsPullRequestData) accepts a array of resolved items under merged-items (List<WsMergedItem>). The server processes this array simultaneously in a single rebase-continue step:
```
POST /vco/api/content-repositories/requests/pull
{
  "merged-items": [
    { "old-path": "...", "new-path": "...", "data": { ... } },
    { "old-path": "...", "new-path": "...", "data": { ... } }
  ]
}
```
Retrieving Conflicts: When a pull request status returns MERGE_CONFLICT, the response's details field provides a paths array listing all conflicting paths for that specific step.
Client Implementation: Automation clients can extract all conflicting paths from a single GET response, programmatically construct the incoming-side data payload, and submit all resolutions in a single batch via merged-items.

3. Is there a maximum limit on conflict items per pull request, and what is the recommended procedure if exceeded?

There is no explicit hard cap built into the conflict-resolution processing path.
Recommended Procedure: For repositories with thousands of divergent items, update your API client to submit all paths from each conflict payload in a single merged-items batch per rebase step, rather than executing manual chunking or full repository resets.

Additional Information