Magento 2 REST API Bug: Inconsistent Attribute Set Listing Without Sorting

Unpacking a Critical Magento 2 REST API Inconsistency: Attribute Set Listing Anomalies

For e-commerce businesses leveraging Magento 2, robust and reliable API integrations are the backbone of seamless data synchronization, product management, and platform migrations. However, even core APIs can sometimes present unexpected behaviors, leading to data discrepancies and integration challenges. This community insight delves into a significant inconsistency reported within Magento 2's REST API, specifically affecting the retrieval of product attribute sets.

The Problem: Missing "Default" Attribute Set and Pagination Glitches

A recent GitHub issue (#41036) brought to light a peculiar bug in the GET /rest/default/V1/products/attribute-sets/sets/list endpoint. Developers observed that when this API is invoked without any explicit sortOrders specified in the searchCriteria, the crucial "Default" attribute set is conspicuously absent from the returned items array. While the total_count correctly reflects the total number of attribute sets (including "Default"), the actual list of items is incomplete.

This inconsistency extends to pagination as well. The issue author demonstrated that without sorting, the API could return duplicate records across different pages, further complicating data retrieval and ensuring complete and accurate datasets. For instance, an attribute set with attribute_set_id:108 was shown to appear on both page 1 and page 2 when no sorting was applied, despite total_count indicating a larger number of unique records.

Reproducing the Anomaly

The steps to reproduce this bug are straightforward, highlighting the clear difference in API behavior:

• Without Sorting: Executing a request like the following will omit the "Default" attribute set from the items array:

GET /rest/default/V1/products/attribute-sets/sets/list?searchCriteria[currentPage]=1&searchCriteria[pageSize]=100

• With Sorting: Conversely, adding any valid sort order, such as by attribute_set_id, ensures that the "Default" attribute set is included in the response, and pagination behaves as expected:

GET /rest/default/V1/products/attribute-sets/sets/list?searchCriteria[currentPage]=1&searchCriteria[pageSize]=100&searchCriteria[sortOrders][0][field]=attribute_set_id&searchCriteria[sortOrders][0][direction]=asc

The discrepancy is evident in the responses: the sorted request correctly lists the "Default" attribute set ("attribute_set_id":4, "attribute_set_name":"Default") at the beginning of its items array, while the unsorted request does not.

Implications for Developers and Merchants

This bug carries significant implications, particularly for:

• Data Migrations: When migrating product data from external systems or older Magento versions, ensuring all attribute sets are correctly identified and transferred is paramount. Missing the "Default" set could lead to incomplete product definitions.
• Third-Party Integrations: Any integration relying on this API to fetch a complete list of attribute sets – for PIM systems, ERPs, or custom applications – could inadvertently miss critical data, leading to synchronization errors or incorrect product assignments.
• Custom Development: Developers building custom modules or scripts that interact with attribute sets via the REST API must be aware of this behavior to avoid unexpected omissions.

Immediate Workaround and Best Practices

While an official fix from Magento is pending (as no resolution was provided in the issue comments at the time of this insight), the issue itself points to a simple, effective workaround: always provide a sortOrder when querying the /V1/products/attribute-sets/sets/list endpoint. Sorting by attribute_set_id or attribute_set_name in ascending or descending order appears to resolve the inconsistency, ensuring all attribute sets, including "Default," are returned correctly.

This incident underscores the importance of thoroughly testing API endpoints, especially during critical phases like platform migrations or major integration projects. For Shopping Mover clients, understanding such nuances is crucial for smooth transitions and maintaining data integrity on their new Magento 2 or Adobe Commerce platform.

We encourage developers and merchants to monitor the original GitHub issue for official updates and patches. In the meantime, implementing the sortOrder workaround is a recommended best practice to ensure reliable attribute set data retrieval.