Send pinnedVersion in AI catalog bulk enablement

What does this MR do and why?

This MR sends pinnedVersion in the aiCatalogItemConsumerBulkCreate mutation.

The frontend already builds a pinnedVersion value, but a condition sent it only in the single-project mutation. This MR removes that condition. The condition was needed once: the bulk mutation had no pinnedVersion argument when bulk enablement was first built. A backend merge request added the argument later.

The change matters because of a timing gap. When the frontend sends no version, the backend picks the latest released version at request time. The item page can show an older version. If someone publishes a new version while the page is open, the old code pinned that new version. The user never saw it. The single-project mutation already sent the viewed version, so bulk enablement was the inconsistent case. Both now pin the version the user saw.

addItemToTarget also reuses the existing activeVersion computed property instead of repeating a getByVersionKey call.

References

Screenshots or screen recordings

Not applicable. This change does not affect the user interface.

How to set up and validate locally

  1. Create a public agent in project A. Publish it. It now has version 1.0.0.

  2. Open that agent from Explore > AI Catalog. Keep the tab open. Do not reload it.

  3. In a second browser tab, edit the same agent and publish it again. It now has version 2.0.0.

  4. Return to the first tab. Do not reload it. Select Enable. Select projects B and C. Select Enable again.

  5. Open the browser developer tools. Find the createAiCatalogItemConsumerBulk request. Confirm the payload contains "pinnedVersion": "1.0.0".

  6. In a Rails console, confirm both new records pin version 1.0.0 and not 2.0.0:

    Ai::Catalog::ItemConsumer.where(item: Ai::Catalog::Item.last).where.not(project_id: nil).pluck(:project_id, :pinned_version_prefix)

Do not select project A in step 4. The backend ignores pinnedVersion when it enables an item in the project that owns the item. It always uses the latest released version there.

Without this change, step 6 returns 2.0.0.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Justin Ho Tuan Duong

Merge request reports

Loading
Loading