I'm not sure if this is the right place to report this, but we encountered the following issue
After an incident where the indexer had been stopped prematurely in production, we noticed that the commerce importer was throwing ‘primary key violation’ exceptions every now and then. The reason for the above, was found to be that the SP does not take into consideration that an entry in the CatalogItemChange table can already exist with the values for the given catalog entry and catalog, with IsBeingIndexed = 0. Since the table has a combined primary key consisting of all 3 values, it then threw an exception, when trying to create the new record.
For us, In order to get around the ‘primary key violation’ exception, the where-clause of the SP was changed from just, naively, looking at whether or not a record with IsBeingIndexed = 1 exists, to check if a record with IsBeingIndexed = 0, for that catalog entry and catalog, exists. The change is not simply swapping a 1 for a 0, as can be seen later.
I would however like an oppinion on this issue and our solution :) In my oppinion it should not try to insert an entry if the same entry is already queued and pending indexation
I'm not sure if this is the right place to report this, but we encountered the following issue
After an incident where the indexer had been stopped prematurely in production, we noticed that the commerce importer was throwing ‘primary key violation’ exceptions every now and then. The reason for the above, was found to be that the SP does not take into consideration that an entry in the CatalogItemChange table can already exist with the values for the given catalog entry and catalog, with IsBeingIndexed = 0.
Since the table has a combined primary key consisting of all 3 values, it then threw an exception, when trying to create the new record.
For us, In order to get around the ‘primary key violation’ exception, the where-clause of the SP was changed from just, naively, looking at whether or not a record with IsBeingIndexed = 1 exists, to check if a record with IsBeingIndexed = 0, for that catalog entry and catalog, exists. The change is not simply swapping a 1 for a 0, as can be seen later.
I would however like an oppinion on this issue and our solution :)
In my oppinion it should not try to insert an entry if the same entry is already queued and pending indexation
Thanks in advance