Strange log messages

And some more…

2022-09-12T10:17:02+00:00 WARNING No remote ID found for local ID 13066
2022-09-12T10:17:02+00:00 NOTICE Job ‘unlink-product’ with ID 5417
failed 1/3 times and will run again

Hello @markisu72

thank you for reaching out to us, we are here to help.

I believe these notifications are not affecting the site. When all the products are initially being synchronized, there are sometimes entries created that in the end don’t get utilized, but are disregarded because of issues that occur during the initial sync (they are dropped). Then later, when an update occurs, it can cause these error messages to be generated; the system has got the UUID (main key between the libraries) still in the database, but no products are connected or rely on its existence.

I know it can be worrying, but there are only 2 options for making sure the plugin is functioning correctly:
1) Verifying the products and stock is synced correctly (this is a bit intensive, but you can just check the adjusted/sold/added products and see if those have the correct details/numbers.
2) Check the Zettle Database of the products that were seen in the logs. you can review the details of the UUID and see if the products that were mentioned in the logs have got the correct details/numbers. This is a bit more direct approach, but if it is the logs that worry you, this might be what you want to do.

You can find the related database entry under the name WP_ZETTLE_WOOCOMMERCE_ID_MAP. In this entry you will find the product ID and the UUID, so you can identify what product is related to what error.

Our developer told me that there were discussions in the past to remove these logs, but since they don’t harm the process, they decided they rather have too much instead of possibly missing information in the logs.

There is one error that is possibly more worrying: “Stock management at variation level is not supported from PayPal Zettle”. I think it could be that you have both the stock management of the main product and the variations activated for that product and this will most likely cause issues. But like above, you need to find out what product this is related to.

Let me know if you want to further investigate this and/or if you require any help with this.

Kind regards,
Joost

Hi @joostvandevijver ,

thanks for the answer – I can work with this!
I will keep you posted

Thanks
Markus

Hi @joostvandevijver ,

I analysed it a bit further:

2022-09-09T14:11:02+00:00 WARNING Stock management at variation level is not supported from PayPal Zettle. ID:2699
--> This is a variant, but stock level is only enabled on variant level and sync works flawlessly in both directions. No clue why there is a warning

2022-09-12T10:17:02+00:00 WARNING No remote ID found for local ID 13066
--> product is a variant and it's being synched flawlessly in both directions. No clue why there is a warning

2022-09-12T10:17:02+00:00 NOTICE Job ‘unlink-product’ with ID 5417
--> this is strange, because the ID belongs to an order, not a product

Can you make sense of it?

Thanks
Markus

Hello Markus,

the last ID in these notices is just our job ID in the queue, not a product ID. The other 2 error could be a failed attempt, but I can’t be sure.
The logs are created to be analysed when you encounter an issue. You are trying to find issues by analysing the logs. I do not think this will get you much useful outcome, since there are many entries created without any “real issue” occurring.

Sorry that I can’t give you the exact explanation of these errors.

Kind regards,
Joost

Hi @joostvandevijver ,

ok, thanks for the feedback…
The issue is: we have multiple hundreds of products and variants.
Thus, it would be pure luck if I accidentally find issues.

That’s why (and I love detailed logs) every now and then, checking the logs is no bad idea in general.
At least given, the log levels used are somewhat close to common understanding.

Usually, log level “warning” can mean anything between “might not imply any issue but if reoccurring, you might want to check the root cause” to “might imply harmful situations”.

Since (this is no understatement), the sync between online and offline world is really critical to business, everything which raises a warning could be potentially harmful.

But I take your advice, that in this case, I should not read the logs like that.
Still, this situation does not give me a good feeling…

Maybe it might make sense to adapt the log levels of those messages so they relate better to the actual situation they report (or have a documentation how to read the levels).

Thanks a lot for your explanation ??

Greets from a developer ??
Markus

Hello @markisu72

I completely understand your situation and would also like to get rid/filter out of all none affecting messages, so you can use them the other way around. However, this was discussed and we fear that if we do that, we might also filter out messages that are vital for identifying the cause of an issue when it is encountered.

For now, I will create a new feature request for this and see if we can work on something that can help us better understand the logs and place them in the right priority or add a filter in order to select what you see when reviewing/generating the logs. I will link this to this thread, so I might contact you in the future if the input is needed or if we have any version to be tested. If you are ok with it, I will mark this thread as resolved.

Your input on and understanding of the situation is very much appreciated!

Kind regards,
Joost

Hi @joostvandevijver ,

removing them is not necessary – maybe just lowering the log level would already be sufficient to reduce confusion without losing any information…

Thanks a lot for your support, I appreciate it a lot!
Markus

good point, added this to the feature request. Thank you!

Hello @markisu72

I discussed this today with the product owner and lead developer and we decided that there is no useful way to introduce this adjustment. The logs are there to look up details in case of an issue. What you are looking for is a way to find issues by looking at the logs and this is simply not how it can work because it will not be reliable.

We are afraid any such adjustment will do more harm than help clear up logs, so we closed this feature request. Sorry that we can’t help you out on this matter.

Kind regards,
Joost

Hi @joostvandevijver ,

thanks for your feedback.
Working in software development since now for about 30 years, my understanding of log files is different. Usually, a log file has two purposes:

a) gaining information when backtracking issues which were identified (as you described)

b) learning about issues which might have slipped through, _before_ they do harm

In fact, the latter aspect is the most important one.
That exactly is why log levels (info, warn, error, fatal) were introduced in the first place.

When operating a production environment, scanning log files for e.g. warn, error or fatal is basic to keep the system alive.

Usually, in the logs you find potential issues _before_ they are accidentally observed, e.g. by customers. That is why usually operations departments monitors log files – just to be ahead of the customer.

Keeping the stock in sync between Zettle and Woo is absolutely critical (and basically the sole purpose of the plugin).

If the idea is to check the log files _after_ an issue was observed (e.g. by a customer ordering an item which is no longer available) that means, there is some information in the logs to track the issue down.

So why not check the log files for these patterns and fix the issue manually _before_ it impacts the customer?

Best
Markus