Hi, I am currently facing issues with import/ search: After running the Import and P&S without a

ULL0N440J

Hi, I am currently facing issues with import/ search:
After running the Import and P&S without any errors the search appears to lack of some entries. This probably causes the behaviour, that I have some products in Yves which are visible, but when I open the PDP it says "No route found".

Digging deeper: the spy_product_abstract_page_search table has less entries than it should have (compared to spy_product_abstract).

What I've done so far:

• Rerun Import + Trigger/ Sync -> no errors, nothing in error queue
• search:setup + rerun product trigger -> nothing changed.

Any ideas?

UKTSRTD5M

Perhaps you can try to find an abstract product which is missing in the _page_search and visit this product in the zed ui. Perhaps you can spot anything there (such as a missing store-relation)...

UKHR9UN00

Hi Daniel,
maybe not all products match the criteria to be published in search.
You can have a look at \Spryker\Zed\ProductSearch\Persistence\ProductSearchQueryContainer to see what data is expected.

ULL0N440J

@UKTSRTD5M seems like there are some references to categories missing 🤔 Will check this and keep this thread updated.

ULL0N440J

So.. The product which I couldn't open in Yves was actually not imported recently (wasn't in our import csv's - but it remained in Zed as active). We'll have to overthink how our import is working and what we might clear before importing

ULL0N440J

We're setting all of our products to inactive before starting the import now.
What have you done so far to get rid of outdated products? 🤔 In our case we get a complete list of all products and we're importing these at night (takes between 90 and 120 minutes)

UKTSRTD5M

Lucky you, our nightly import is about 3 1/2 hours (therefore we introduced a green/blue deployment of redis and elasticsearch, which in itself is taking up some additional time to sync all items again, but removes downtimes to nearly 0) 🙂 We do not delete products during this process, as our products are relatively stable. We provide a status via some other (realtime) mechanism (ERP calling Zed directly on change) and then remove the store relations when a product gets unavailable. But e.g. for categories we did it like: (1) flag everything beforehand, (2) import, remove flag on updated items, (3) after the import: removed all flagged entries.

ULL0N440J

Sounds good to request the amount in stock on the fly. Wish we could apply this, but our current delivery of data doesn't provide an API afaik. Most of our products (slightly more than 60k in Shop 1, in Shop 2 we're running about 85k) have a different price every day. Think it would be quite expensive to compare if a product needs to be updated or even created at all.

We're now setting every product to inactive before importing. This flag is overwritten by import directly.

UKTSRTD5M

And no one is using the shop while you are importing?

UKTSRTD5M

or after a deployment, when the new version expects some data to be present in redis?

ULL0N440J

And no one is using the shop while you are importing?

We're importing at night, so it's not that likely at the moment. You can use the shop while import is running, it's running on its own instance. Zed is separated.

or after a deployment, when the new version expects some data to be present in redis?

We usually don't flush/ clear redis on deployments (as long as not necessary. Then we'd probably run a full import)

UKTSRTD5M

I'm talking about some specific, newly added data, which is not present in redis until everything is reimported after the deployment. If you wanted to avoid downtime here, you're in trouble without any kind of decoupling. But if can accept downtimes during the night, that's not as important... Again, lucky you 😉