Skip to main content

Bulk Product Selection fails when a custom category attribute conflicts with the reserved category response

Updated

Overview

Bulk Product Selection may display a Failed to Load error even when the submitted product IDs are valid, and the products exist in the latest index.
 


This issue occurs when a feed contains both:

  • The valid category_paths system attribute, which defines the product’s category hierarchy.

  • A separate custom attribute named category.

For Discovery, category_paths is processed into the internal search_category field. The FE API returns that field as a category. A second feed attribute named category creates a naming collision in the downstream response path.
 

Cause

The feed contains the following additional attribute:

"category": [
  "1862918192",
  "categories",
  "1862918091",
  "1862918196"
]

This is a flat list of IDs and the value categories; it isn't the structured category-path value used by Discovery.

The same feed also contains a valid category_paths attribute, for example:

"category_paths": [
  [
    {"id": "categories", "name": "Categories"},
    {"id": "1862918091", "name": "Parts & Service"},
    {"id": "1862918192", "name": "Filtration"},
    {"id": "1862918196", "name": "Air Filters"}
  ]
]

The category_paths structure isn't the problem. It correctly represents category nodes with IDs and names. The problem is the additional field named category, because category is used as the reserved API response name for category data generated from category_paths.

When the FE request builds category facets, the separately supplied category value can be selected instead of the correctly generated category data. The resulting facet values don't contain the expected ID/name format. This causes the FE API to fail while parsing the Solr response, which appears on the Dashboard as "Failed to Load".

The similarly named categoryPath attribute is also a separate custom field. It doesn't replace category_paths and isn't the root cause identified in REPCO-185.

 

Solution

  1. Remove the separately supplied custom attribute named category from the feed.

  2. Continue sending the category hierarchy through category_paths.

  3. If the raw flat list is required for another business purpose, rename it to a non-reserved name, such as repco_category_ids.

  4. Resend the affected product records.

  5. Complete a new index update and retry Bulk Product Selection.

Incorrect structure

{
  "attributes": {
    "category": [
      "1862918192",
      "categories",
      "1862918091",
      "1862918196"
    ],
    "category_paths": [
      [
        {"id": "categories", "name": "Categories"},
        {"id": "1862918091", "name": "Parts & Service"},
        {"id": "1862918192", "name": "Filtration"},
        {"id": "1862918196", "name": "Air Filters"}
      ]
    ]
  }
}

Corrected structure

{
  "attributes": {
    "category_paths": [
      [
        {"id": "categories", "name": "Categories"},
        {"id": "1862918091", "name": "Parts & Service"},
        {"id": "1862918192", "name": "Filtration"},
        {"id": "1862918196", "name": "Air Filters"}
      ]
    ],
    "rep_category_ids": [
      "1862918192",
      "categories",
      "1862918091",
      "1862918196"
    ]
  }
}

The customer should not add another standalone category attribute. Bloomreach generates the reserved API response field category from category_paths.

Please take a look at the Category Paths documentation and Reserved attributes documentation for the supported category mapping.
 

Summary

The customer is sending the correct category_paths structure, but is also sending a second attribute named category. Because category is a reserved response name generated by category_paths, the two fields collide, resulting in malformed category facet data. Removing or renaming the additional custom category field, followed by reindexing, resolves the Bulk Product Selection failure.