Naguel

I'm Nahuel, and these are my work experiences, ideas and thoughts as a web developer working on the eCommerce industry.

Magento and a deadlock found when trying to get lock

Magento and a deadlock found when trying to get lock

"What now?" issues every now and then with Magento are the norm, and I got this one a few days ago:

SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction, query was: INSERT INTO `catalog_product_index_eav_temp` SELECT DISTINCT [...]

Apparently the server went down for a second, or MySQL went down... or something happened and a reindex process was interrupted (in my case the one for the "Product EAV" index), and there was no way to make it work again.

Even the usual bin/magento indexer:reset and then a manual reindex with bin/magento indexer:reindex didn't do the trick and the only difference was that instead of the previous error I was getting the classic one.

Product EAV index is locked by another reindex process. Skipping.

Lucky me, I find the following on Twitter.

Basically, when you have no way to "unlock" an index, and after you already tried the reset and manual reindex, just change that prefix in your app/etc/env.php file to something new, then reset and finally try to reindex again.

That alone should do the trick.

Add related posts to Ghost blog

Add related posts to Ghost blog

The related posts are quite easy to add to Ghost if you have some basic knowledge on how to edit your current theme (there's no option to turning this ON and OFF on the Admin, unfortunately, so you must do it on the theme itself).

If you open your theme's files you would see a post.hbs template which is the one for the articles (for "this page you are seeing right now", basically), and the block expression {{#post}}...{{/post}} would be the one containing everything related to the post itself.

Outside that expression, after it, we want to add the related posts taking advantage of the {{#get}} helper.

{{#get}} is a special block helper that makes a custom query to the Ghost API to fetch publicly available data.

get documentation for Functional Helpers by Ghost

Clearly, you can use this helper to get the related posts anywhere you want, like on the sidebar of the blog if yours have one, or in a page instead of a post (but I personally like them at the end of an article).

Let's say you would like to get a list of related posts based on the tags of the current one, which can be done by filtering the data on the filter attribute.

{{#get "posts" filter="tags:[{{post.tags}}]+id:-{{post.id}}" as |related|}}
	[...]
{{/get}}

In this case the filter attribute also contains id:-{{post.id}} to ignore, from the list of posts we are getting, the current article (we wouldn't want to suggest as related post the same post the user just read).

You can add as many filters as you want using the + sign as separator.

Inside this helper, the related "object" will be the one containing all the related post, so you just need to "loop it".

{{#get "posts" filter="tags:[{{post.tags}}]+id:-{{post.id}}" as |related|}}
    <div class="related-posts-wrapper">
        {{#foreach related}}
            <article class="{{post_class}}">
                <a href="{{url}}">{{title}}</a>
            </article>
        {{/foreach}}
    </div>
{{/get}}

Once inside the foreach you are in the context of the post, and then you can just get whatever you want from that post such as the {{url}}, {{title}, etcetera.

You can limit how many post to show by using the limit attribute on the {{#get}} helper (15 by default, which seems like too much)

{{#get "posts" limit="2" filter="tags:[{{post.tags}}]+id:-{{post.id}}" as |related|}}
    ...
{{/get}}

The related posts can be anything you like and you would like to consider as related posts, as you are not limited to that filter for the tags I used as an example.

I'm currently using tags:[{{post.primary_tag.slug}}] within the filters to only consider those posts that have the primary tag of the current post as a tag in any position, as I think those posts would be more relevant to the current one.

{{#get "posts" filter="tags:[{{post.primary_tag.slug}}]+id:-{{post.id}}" as |related|}}
    ...
{{/get}}

This is not the same as using primary_tag:{{post.primary_tag.slug}} which is another filter option, in this case to get only those posts that their primary tag is the same as the current post (there's a slightly difference).

Optionally, you can use the featured:true filter option to get those posts that are checked as featured within the Admin.

{{#get "posts" filter="tags:[{{post.tags}}]+featured:true+id:-{{post.id}}" as |related|}}
    ...
{{/get}}

If you have multiple writers in your blog and you want to show related posts where the current author also participates you can use the authors:{{post.primary_author.slug}} option within the filters.

{{#get "posts" filter="authors:{{post.primary_author.slug}}+id:-{{post.id}}" as |related|}}
    ...
{{/get}}

This is different than using primary_author:{{post.primary_author.slug}} where we are filtering by those posts where the primary author is the same.

Refer to the get documentation on Ghost for more ideas on how to filter.

Screwing up badly at work

Screwing up badly at work

Recently I changed some configuration on a client's site that triggered thousands of emails to different customers, forcing our client's Customer Service to handle the same amounts of customers calls on a day that they would have on a normal week, and finally having our client writing an apology email for all affected users saying that there was no data breach in the site.

It was a long day.

Admit it

Shit happens, and people make mistakes. I did on that occasion, I probably will again in the future or somebody else will, but I will be happy if we as a team don't make the exact same mess I did.

The first thing to do when you screw up is to admit it: tell somebody that you screwed up and tell that person how you screwed up exactly.

If there's a big problem, and you alone caused that problem, chances are people will be chasing ghosts to fix something they won't understand completely how it started (if you don't come forward and tell them exactly what happened).

You are the only one that knows, basically (until everybody finds out).

The idea is to change everybody's mind from panicking about a mystery error to focus on how to put down the fire and doing some damage control. Back to my example, everybody was wondering how the emails went out but when I told them it was me changing a setting then everybody move towards finding a solution (emails were still going out at that point).

Really, trying to cover up something is really a stupid idea because, again, shit happens and it shouldn't be the end of the world, and people will find out rather sooner than later.

Say sorry as you should be

Being on the defense on this type of situations is pretty common, but you shouldn't be. You made a mistake, you admitted it, now apologise without making excuses or blaming something (or somebody) else.

As individuals and as a team we should learn some stuff starting with the fact that human error is an actual thing. Saying sorry is as important as learning to accept someone's apology.

Keep in mind that if you didn't screw up this time you could be the one causing the mess next time, so don't believe you are so perfect. At the same time, if you were the cause of all the problems today, relax, somebody else will take the leading role next time.

Not the same mistake twice

When the adrenaline is over and the problem is solved do everything within your reach to avoid the same mess to repeat itself.

Let's try to have new problems, not always the same ones (it's boring that way).

While all human errors can't be eliminated (unless there's no human in the equation) we can always reduce the chances for them to happen by identifying what mechanism we (the team) can put in place to prevent them.

Back to my emails, the setting I changed wasn't on the Live site but on a testing environment, that happens to contain real customer data. In this case the problem was on how we create those testing environments (a fault on the process we have in place for doing that).

The problems could be prevented by improving the processes, adding any necessary documentation, and most important by spreading the information across the team.

Learn from a mistake is not a cliche phrase but instead it's something "tangible".

If you really learned from a mistake you will ended up with more documentation available to the team, a better process in place, and everybody informed of what happened and what can be done to avoid it happening again.


Always keep in mind that La La Land was announced the winner of the Best Movie category in the The Oscars ceremony because somebody handed the wrong envelope. And they improved the process for the following events.