7

I'm experiencing a rare issue where existing customers completing checkout place the order successfully. However, the following strange behavior occurs:

  • The order confirmation email is not sent,
  • The order is assigned to the customer correctly, yet customer_id is set to 0, and
  • If the customer places the order again, it works correctly (order confirmation email sent and customer ID assigned correctly) however, the increment_id assigned is precicely the same as the first order and as a result there is a duplicate order increment id, with both orders active.

As I mentioned, the issue is quite rare, we receive over 20 to 30 orders a day, and it only seems to happen once a day, if that.

Edit: as per comment, it is useful to note that I am using an extension which allows alphanumeric order increment_ids, Aschroder Set Custom Order Number, our orders follow a trend as follows: OR1000, OR1001, OR1002, OR1003, etc. We have been using this extension for over 10,000 overs without this issue appearing before.

I am also using ASchroder.com SMTP Pro Email - Free and Easy Magento Emailing for SMTP, Gmail or Google Apps email to integrate google mail support for Magento.

Update 1: Looking at exception.log the following entry is notable which occured around the time of the incidents:

 'Zend_Mail_Protocol_Exception' with message 'Unable to connect via TLS' in /html/lib/Zend/Mail/Protocol/Smtp.php:211

It seems like this could cause the order creation process not to reserve the order increment id on the quote model.

Is there a way that I can diagnose what is causing this behavior? All other orders placed seem functionally correct.

Moose
  • 7,495
  • 7
  • 48
  • 91
  • Are you using any 3rd party/custom checkout module? Any insight in /var/log/exception.log or /var/log/system.log? If you have logging enabled or not. It sounds like Foreign Key restraints. Also what are you using for your session storage in local.xml? – B00MER Feb 26 '14 at 09:05
  • I've edited the question to reflect an extension we're using for increment_ids to be alphanumeric. In terms of local.xml, <session_save><![CDATA[files]]></session_save>. Regarding the error logs, something noteable which happened around the time of order placement was exception 'Zend_Mail_Protocol_Exception' with message 'Unable to connect via TLS' in /html/lib/Zend/Mail/Protocol/Smtp.php:211 – Moose Feb 26 '14 at 09:11
  • Regarding the exception.log issue with the email, could it be possible that Magento does not complete reserving the order increment id if the email fails to send to the customer? – Moose Feb 26 '14 at 09:18
  • Ashley is on here and maybe of help. I sent him a tweet with this issue. https://twitter.com/molotovbliss/status/438618372142415872 – B00MER Feb 26 '14 at 10:17
  • Might not be related to your issue, but watch out with alphanum order IDs. Magento has a bug in sales/quote resource model (fixed during the Hackathon): here the increment is cast to int, see isOrderIncrementIdUsed(). This gave us some headaches in a multistore installation. – fmrng Feb 26 '14 at 10:27
  • @fmrng: that is strange, did removing the int cast resolve the issue in your instance? – Moose Feb 27 '14 at 06:19
  • @moose: yes it did, but like I said I'm not sure if this is related to your problem. – fmrng Feb 27 '14 at 13:48
  • Does SetStartOrderNumber allow alpha-numeric?! Are you sure you're using it? SMTP Pro has detailed logging in system.log have you checked in there (you need to enable logging)? – Ashley Schroder Feb 27 '14 at 23:30
  • @Ashley Schroder: It does indeed, with the order prefix enabled. The values stored in sales_flat_order under increment_id are alphanumeric. I did post the error message in system.log in my first comment, the Zend_Mail_Protocol_Exception issue. Still not quite sure what caused the issue, it's happened once again since then. – Moose Mar 05 '14 at 08:36

0 Answers0