Sorry - it wasn't meant to leave issues unaddressed or bury the hatchet, hence the first answer in the FAQ above that makes the intentions of this new thread quite clear. I don't know how to make the purpose of this thread more clear than having it as the first point in the FAQ - suggestions are, of course, welcome.

I am in the process of dealing with several unresolved bits in that previous thread. Also, that comment about correlation obviously wasn't addressed to you, as it was addressing the correlation between the person who had his hardware and wanted the frame quickly, yet chose a really slow shipping method. Yours is obviously not the case, and that is why that comment was specifically addressed to the person I was replying to.

Ok so first things first - with regards to the customers, such as yourself, affected by the incorrect shipping method being displayed on the front-end. I was first alerted to that in this thread, and by that stage all of those orders had shipped. Respectfully, what would have been your suggestion on handling it, knowing that we are a boot-strapped startup running on quite thin margins, and belong to a group of companies that has a board of directors to answer to? We can't afford to re-manufacture everyone's order and ship them out. We can't notify customers as we actually don't even know how many orders, and which ones, are affected - we don't log the full text of outgoing mails, unfortunately. Additionally, whilst you may be a genuine, trustworthy individual, we've already had known scammers purchasing from us, we have to be cognisant of being taken advantage of. After all, we've already had at least 1 well known scammer order from us (see previous thread), so it's not like we can account for every customer's ethics.

That having been said, we are fully aware of the mess up. I hadn't addressed this in the previous thread, as I spent some time on the weekend rolling back the database on test to various points at the end of November to see the problem, and I hadn't quite finished my investigation. I think I'm at a point where I know enough to discuss it, though I would've liked to remove the troll-distraction today so I could've finished what I started. At any rate, technical discussion ahead (if you don't care about technical stuff skip ahead two paragraphs) - the root cause of the problem was our full page caching system. In order to make AJAX calls faster, certain pieces of AJAX-requested content (such as the JSON array of enabled shipping options) was cached by the FPC. At any rate, the shipping options were returned with their foreign key, and then subsequent calls can use the key and the session to request a shipping price. (Sidebar: we've since changed this so that there is no caching, and shipping calculations are all done on-demand with a JSON array returned...the reason it existed in the first place is that many of our web properties use a single shipping option, so there are never multiple subsequent calls - it's the nature of reusing a more general working architecture, sometimes you have stuff that is irrelevant to your current solution) Since the foreign key was cached, and we'd changed the underlying data sources (which isn't a db table, so no cascading referential integrity) the fk now pointed to the wrong pk. The reason we can't tell how long this change lived is because the cached JSON data is stored in /dev/shm and served via nginx's X-Accel-Redirect (basically nginx's equivalent of Apache's X-Sendfile), and cached JSON data is expected to be long-lived (so on a slow refresh cycle). Also, /dev/shm is excluded from duplicity, so it won't appear in a remote backup set.

However, there was a snippet I managed to find. Session-specific pages cached by our FPC aren't served off /dev/shm due to size constraints (only more generic pages such as the product and info pages). That cache location is excluded from hourlies but not excluded from dailies. The only session-specific page that is cached by the FPC that contains actual shipping info is the cart page (not the checkout, too dynamic) which gets destroyed every time a change is made to the cart in the session. Whilst not many use the shipping estimator (instead choosing to barrel ahead to checkout to see shipping options), there were a few so that I could see what an actual front-end user would see when using the shipping estimator.

What I found is that there were two options shown to the user: Airmail and EMS. No surface mail, no Aramex. Airmail (which had surface mail's fk) was first on the list and the cheaper of the two, EMS was noticeably more expensive (in reality, and now that it's fixed, at the weight we're shipping these two have a lot of parity). Also, there were no timelines listed. So, generally speaking, customers choosing airmail didn't opt for a specific timeline or delivery period. They saw two options and chose the cheaper of the two. Please understand that I'm not trying to make excuses for the error, but I do see a logical fallacy with users purporting that they chose airmail because it was "faster" when it was the cheapest option. What I had hoped to uncover is that surface mail existed at the same price or lower and they chose airmail, in which case it becomes easier to make a case, you understand? At the end of the day with something like this I also have to go back to the group directors (of which I am one, but far from the majority shareholder of the group) and discuss it with them, and they most assuredly will view things clinically and with a disconnect. It becomes especially complex as we have had some users (with orders on the same day as yours) in the US receive their surface mail shipment within 4 weeks of transit, and several EU customers receive it at the 5-6 week mark, so it's not like it's universal.

Yet, as you have pointed out, we did screw up. That is why on an individual level we are attempting to assist customers. We cannot do this on a blanket basis for the aforementioned reasons, but we can see what we can do to assist customers individually - and you've seen those efforts in the previous thread. So wobbzz, hit me up offline on ric@openrigs.com or via pm, and I will see what I can do help you and to establish with your local postal service if the parcel is, in fact, in the country but simply not tracking correctly.