vSphere Automation REST API tag category creation can create duplicate categories when requested near simultaneously

Products

• VMware vCenter Server
• VMware Cloud Foundation

Issue/Introduction

• vCenter's tag category creation feature does not allow creating a category if it already exists in vCenter.
• When attempting to create duplicate tag category names in the vCenter web user interface (UI) the request will fail with "Tag Category Already Exists" error 
• If requesting tag category creation for multiple tag categories with the same name within a short time frame (approximately 2 seconds or less) using the vSphere Automation REST API, there will not be an error and duplicate tag categories are created in vCenter
• If this creation attempt occurs after a longer period, the API returns the expected error "ALREADY_EXISTS"

Environment

vCenter 8.x, 8.0.3

VCF: 9.0, 9.1

Cause

This behavior is due to a timing-window issue, not a logic defect in the code.  When two (or more) requests to create a category with the same name arrive close enough together, each request independently checks "does a category with this name already exist?" before the other request has finished writing its new category.

If both checks run before either write completes, both checks come back "no," and both requests proceed to create a category — resulting in the duplicates.

Resolution

Workaround 1: Route category/tag creation requests through a single serialized worker

If your automation already uses a job queue or scheduler, have all "create category X" requests — regardless of which user triggered them — get submitted to that queue and processed by a single consumer, one at a time. This forces only one creation request at a time and prevents the race condition.

Workaround 2: Use a shared lock keyed by category/tag name

Introduce an explicit lock that all automation processes acquire before their check-then-create sequence and release after. The lock should be keyed by the category name (or category+tag name for tags), so unrelated names aren't needlessly serialized against each other.

Workaround 3: Deduplicate at the trigger layer

If the real-world scenario is "the same name gets requested by multiple users nearly simultaneously," consider coalescing those requests before they ever reach the API — if a create request for a given name is already in flight, have subsequent identical requests wait for that one to finish (and pick up its result) rather than issuing a second, independent API call at all.

Workaround 4: Periodic cleanup

Implement a periodic reconciliation job that scans for duplicate-named categories/tags and removes all but the canonical one (reassigning any tag associations first) to catch and correct duplicates after the fact.