Fata Error encountered when Adding to Cart

[joseibarra]

In the past years we have had several incidents where shoppers are able to successfully browse the store but when it comes time to add a product to their cart they get a Fatal Error from Miva such as:

Miva Merchant has encountered a fatal error and is unable to continue...
Error Code: MER-DBP-BIN-00006
Description: mysql_execute: Can't find record in 's01_BasketInfo'

Untitled.jpg

Once some conscientious shopper let's us know of the problem and we open a ticket, we believe the solution is for Miva Support to repair the s01_BasketInfo database.

Miva Support suggested that this is a popular table to become afflicted and they are able to resolve it quickly when notified.
We have learned how to use Plesk to Repair the s01_BasketInfo database ourselves.

The problem is we won't know there is a problem until we get a call from a shopper and that might be a long time for shoppers to be unable to put items in their cart.
This can result in many missed orders.

If you were shopping a site and encountered an error putting something in your cart would you bother to call the site and tell them about it or would you shop elsewhere?

The site is not "down"... The problem is only when adding an item to the cart.

Miva Support suggested using something like Pingdom to tell it the site is up or down but the problem is not that the site is down.
The problem is encountering the fatal error adding something to the cart and we don't see how Pingdom is going to help with that.
The other problem is Pingdom is not free.

Is there a mechanism in Miva so that when a fatal error like that is encountered that Miva could send an email or other notification to the store owner?

If there is no such notification of fatal Miva errors would it be a "Dream Feature" to get something like that added?

The store is still mostly functional, Miva is still "alive" but can it detect these fatal errors and let somebody know about it?

[Kent Multer]

I've never seen that error. If it's happening repeatedly, it suggests that there's something wrong in the server. Maybe Miva needs to do some kind of clean-up or rebuild of your database.

Is it always the same error code & message?

[joseibarra]

We have seen various Fatal Errors over the years but that one dealing with the cart (Basket) are the most popular.

The "solution" is to go to the s01_BasketInfo database in Plesk and choose to Repair it.

My notes tell me that the same s01_BasketInfo database is implicated in some other fatal errors sometimes when deleting things from the cart. I don't have a screenshot of those but the message text is the same:

Error Code: MER-DBP-BIN-00006
Description: mysql_execute: Can't find record in 's01_BasketInfo'
Other Information:

We just want to get a notification of any kind of fatal error so we know there is a problem and not have to wait for some customer to call and tell us about it.

Since the store is still basically functional (except for some things involving the cart), Miva Admin and the storefront is still alive and kicking, how can we get a notification of any Fatal Error so we can fix it ourselves or open a support case to get help.

[alphabet]

You could use the SendEmail function within a conditional.
You could make the conditional as general or specific as needed.:

<mvt:if expr="l.settings:error_messages">
    <mvt:foreach iterator="error" array="error_messages">
        <mvt:if expr="l.settings:error:code EQ 'MER-DBP-BIN-00006'">
            <mvt:assign name="g.to_email" value="g.store:email" />
           <mvt:assign name="g.from_email" value="g.store:email" />
           <mvt:assign name="g.subject" value="'Miva Merchant Fatal Error Report'" />
           <mvt:assign name="g.message" value="'Miva Merchant has encountered a fatal error ' $ l.settings:error:code $ ' : ' $ l.settings:error:description " />
           <mvt:do file="g.module_library_utilities" name="g.email_sent" value="SendEmail(g.to_email,g.from_email,'',g.subject,'',g.message)" />
        </mvt:if>
    </mvt:foreach>
</mvt:if>

I couldn't create a basket error to test so you may have to tweek it yourself.

[Rick Wilson]

Fatal Errors like this happen at the Engine level and outside of the Miva Merchant application which is why you don't get notified. Miva Merchant is not aware of the fatal error.

I also doubt it's a server config error, I would guess something (module or script) is manipulating the database directly and that should really never be done. I do believe our systems team (including David Hubbard) is looking into this.

[joseibarra]

Well thanks for the ideas and for looking into it.

If I were to add the SMT code somehow somewhere I would not be able to test it since I can't recreate the problem - and we are not doing anything in the code other than what comes with Miva.

Miva Support seemed to be aware of the problem since they knew just what to do and mentioned the S01_BasketInfo database as "popular". We have called it in more than once but I don't have all the details handy of dates/times. They just advised to add to Dream Features which I will.

Reiterating the problem for Store Owners is that when the problem occurs no shopper will be able to add things to their cart/basket until the database is repaired and since there is no notification of a problem with the database they must rely on some conscientious shopper to call in the problem and that might take a while...

I'll head to Dream Features later with the topic.

[Bruce - PhosphorMedia]

I don't think the email notification will work as empressa/Merchant may exit processing on this type of record. David? Would this be the case?

[alphabet]

It looks like the error is thrown from the BasketInfo_Clear_Basket function in the basketinfo module:

<MvFUNCTION NAME = "BasketInfo_Clear_Basket" PARAMETERS = "basket_id" STANDARDOUTPUTLEVEL = "" ERROROUTPUTLEVEL = "">
<MvIF EXPR = "{ Basket_ID_Is_Provisional( l.basket_id ) }">
<MvFUNCTIONRETURN VALUE = 1>
</MvIF>

<MvQUERY NAME = "Merchant"
QUERY = "{ 'DELETE FROM ' $ g.Store_Table_Prefix $ 'BasketInfo WHERE basket_id = ? AND clronmod = 1' }"
FIELDS = "l.basket_id">
<MvIF EXPR = "{ g.MvQUERY_Error }">
<MvFUNCTIONRETURN VALUE = "{ [ g.Library_Filename_Utilities ].Error( 'MER-DBP-BIN-00006', g.MvQUERY_Error ) }">
</MvIF>

<MvFUNCTIONRETURN VALUE = 1>
</MvFUNCTION>

I'm wondering if this is a deferred basket / provisional basket issue? Or if your add-to-cart function is creating a race condition?

[joseibarra]

That certainly looks like the right spot - the error is what we have seen on past incidents.

I am not Miva savvy enough to know how to manipulate the code to send a notification when that error occurs - and would not be able to test it since I don't know how to recreate the problem. There might be a way to make an adjustment to the code to notify and then purposely cause a problem with the database to test the notification process. I would not know how to do any of that.

If Miva thinks this is a worthwhile enhancement (like we do) they should make the adjustments and do the testing. I will test if I can.

Talking to Support the issue seems to be that the s01_BasketInfo database has crashed and they can effect repairs to fix it.

Perhaps Plesk can send a notification of a database crash like it can for other incidents like things approaching limits, overages, etc.

I did put a new topic out in Dream Features that references this one so perhaps someday our dream will come true.

[alphabet]

It may be an edge case expired basket issue. I don't own this problem so it is difficult to troubleshoot but here is a possible scenario.

The error occurs when a customer has abandoned the checkout process and returns to the BASK page.

After some time, without reloading the BASK page, the customer tries to update the basket quantity but the Dirty Basket has already expired.

Normally this would result in an empty basket error message but I think there is a lot going on with provisional / deferred baskets and session timeouts.

I would still like to know the answer to Bruce's question in #7.

[Rick Wilson]

Jose,

I don't believe that to be core Miva issue, the staff that could dig into that properly are all on vacation until Monday for the holiday break.

I suspect you'll find either a module is causing the problem or a script interacting with the database directly, neither of which we would fix directly as part of our standard support.

Miva Merchant when it encounters a fatal error of that type is not finding what it expects in the database and errors out, that exception process is outside the world of Miva Merchant actions, so unless something has changed on our end since the last time I had dev look into this years ago, there's no way for Miva Merchant to send you something alerting you to this problem. You'd need to configure some other kind of monitoring like Site 24x7, but far more importantly, this is not happening in core Miva, so you should find out what's at the root and fix it once and for all. This should never happen unless something is very broken.

[joseibarra]

As far as I can imagine when are not using any Miva modules or scripts to interact with the database directly and I wouldn't know how to do that anyway.

[ILoveHostasaurus]

The "solution" is to go to the s01_BasketInfo database in Plesk and choose to Repair it.

My notes tell me that the same s01_BasketInfo database is implicated in some other fatal errors sometimes when deleting things from the cart. I don't have a screenshot of those but the message text is the same:

Error Code: MER-DBP-BIN-00006
Description: mysql_execute: Can't find record in 's01_BasketInfo'
Other Information:

I don't know what domain this is regarding but if a repair (not a truncate) at the MySQL level takes the issue from occurring / reproducible to resolved, then my assumption is that the store is overloading and causing an out of memory condition which affects the database server and results in that table becoming corrupt. This would mean we're talking about a non-enterprise plan where the database resides on the same server as the website. A ticket with support to determine if this is occurring, and why, would be the first step. If it's a performance issue with the store itself, where it cannot handle traffic it is seeing, then the next steps could be determined at that point.

[joseibarra]

We don't know how to reproduce the problem although I am making attempts pretending to be a customer.

We have learned how to fix the problem when it occurs.

Ideally of course it would be best to figure out the cause and fix the problem instead of fixing the symptom of the problem (a crashed database).

For the moment we just want to get notification of when it occurs so we can fix it quickly and not have to wait for a shopper to tell us there is a problem.

if Miva detect the problem and can't initiate an email, Plesk has some notification processes included that will but can it detect and notify of a crashed database?

Are you saying I might open a ticket with Support and say the problem might be: "the store is overloading and causing an out of memory condition which affects the database server and results in that table becoming corrupt. This would mean we're talking about a non-enterprise plan where the database resides on the same server as the website.".

I really don't know what that means.

[Rick Wilson]

I'm sure David will chime in, but yeah contact support with even just that is a good way to start. What you're describing is not a problem with core Miva Merchant, so the Forums are not a good way to unravel this mystery. Without knowing the URL to the store in question, you've likely gotten all of the relevant answers we could provide at this point.

If you're on a legacy shared server (assuming you're hosted with us directly, which is what we mean by a non enterprise plan with a database on the same server) that is overloading, there are 2 most likely reasons that is happening. One is you're running too much traffic/consuming too many resources for that deprecated plan, or your site isn't properly architected and causing the site to go down. Both outcomes are the same, the site runs the server out of memory, corrupting the database and your problem is created.

The solution will be to add more resources or fix your site, depending on what the actual root cause is.