MaxLapDev

The lesser known Rails race condition

2023-12-10T19:00:00-05:00

Note: This post mentions and gives examples in Rails, but the content is relevant to anyone using databases systems, regardless of the use cases.

There are many posts around discussing race conditions in Rails and how to handle/avoid them, but I haven't seen one discussion this particular case.

Simply put, race conditions happen when more than one worker/process/thread interact with the same data and the order those interactions happen in can give undesirable results.

Classical race condition

The classical example of a race condition is having 2 processes altering the same bank account at the same time. Depending on the order that operations happen in, some of the alterations might be lost.

Starting with 100$, if one process does a +10 and another a -15 at the same time. You can end up with each of the following amounts in the account:

110 (wrong)
85 (wrong)
95 (good)

I won't delve into this since there are already lots of articles about and how to avoid it in Rails. Here's one.

The lesser known race condition

Let's think about a single writer and a single reader. Reading some of the articles on Rails race conditions, you could believe everything will be fine.

Consider the database already contains these two records:

Post.create(published: true)
Post.create(published: false)

Now if you have a reader doing a report:

report = {}
report[:total] = Post.count
report[:published] = Post.where(published: true).count
report[:unpublished] = Post.where(published: false).count
puts report

And you have a writer adding some data at the same time:

Post.create(published: false)

Here are the possible reports you might get:

{total: 2, published: 1, unpublished: 1}
{total: 2, published: 1, unpublished: 2}
{total: 3, published: 1, unpublished: 2}

One of these is incoherent. You can't have 2 posts total but then have numbers that add up to 3 at the same time.

This example may feel contrived. It almost always feel like a technicality; the shown result is clearly wrong, but the database doesn't end up with wrong data. You can "just" refresh the page the very few times this happens and the problem will be gone. It's one of those little glitch that no one can reproduce and no one bothers tracking down since it doesn't happen often anyways.

If something like this is in some kind of nightly report, it's not so easy to "just" refresh the page.

But wait, there's more!

You might be tempted to think that this only happens when doing multiple queries on a single table, so you are safe as lon as you query only once per table. If you define the problem as any incoherency caused by the timing, you would be wrong.

If the reader does:

post = Post.find(id)
result = {}
# Querying the posts table
report[:has_admin_comment] = post.has_admin_comment # an attribute
# Querying the comments table
report[:comments] = post.comments # Imagine they are rendered in a page
puts report

And you have a writer adding some data at the same time:

# A callback will see the post's has_admin_comment
# Imagine a call
post.comments.create(by_admin: true, ...)
post.update(has_admin_comment: true)

There is now the possibility that the report contains a comment by an admin while the has_admin_comment attribute says there are no such comments.

So as soon as you do 2 queries, if any of the data of those two queries is related to the other query, there is a chance you'll encounter this. Bummer, I frequently do more than one SQL query in my pages.

A solution

The root of the problem is that we are reading data at different points in time, but we want to treat it as if it was from a single point in time.

The only solution I'm aware of (other than doing only one query), is to tell the database: "Ignore all changes from elsewhere when working on my queries". Where elsewhere means other processes / transations.

In PostgreSQL, that can be done with a transaction with the repeatable_read isolation level. From PostgreSQL's doc:

The Repeatable Read isolation level only sees data committed before the transaction began; it never sees either uncommitted data or changes committed during transaction execution by concurrent transactions.

So going back to our first example, if the reader did this instead:

Post.transaction(isolation: :repeatable_read) do
  report = {}
  report[:total] = Post.count
  report[:published] = Post.where(published: true).count
  report[:unpublished] = Post.where(published: false).count
  puts report
end

Then only the 2 valid reports would be possible:

{total: 2, published: 1, unpublished: 1}
{total: 3, published: 1, unpublished: 2}

Note: In other database systems (such as MySQL or SQLite), it's possible that you need a different isolation level than repeatable_read.

When to solve it?

I think the final question is when should you "solve" this problem? When should you run within a repeatable_read transaction?

I don't know... It depends.

I have never actually tackled this problem in an application-wide manner... yet. So take these suggestions with a grain of salt.

Doing more restrictive transactions can have an impact on performance, can add latency, could introduce deadlocks, could increase the number of transactions that need to be retried. But I'm not sure this is actually a problem in practice.

When starting a new application, I would consider wrapping every request in a transaction and calling it a day. It's too early to focus on scaling/performance in the beginning. The day you grow enough (if that happens) or encounter problems caused to this, then you can either disable this for some request or start doing it only for more critical requests.

For existing applications, wrapping every request could cause new problems to appear:

Existing race conditions you didn't know about might now produce an error. (I think this is good)
Nested transactions can behave slightly differently.
Locks will be held longer, possibly resulting in longer latency and deadlocks.

So is it worth it to wrap every request for existing application? Your guess is as good as mine. Maybe do it,but progressively?

One thing to consider about this is that while you can "just" refresh a page, it's not always so simple. If you are generating a pdf or generating new data from what you queries, then the glitch isn't quite so temporary anymore, is it?

So at the very least, you probably want to use the repeatable_read transaction whenever you are generating something longer lasting than a web page, no matter the consequences.

Code to apply %everywhere

In my case, for my new application, I'm trying it. It's barely any code at all.

Here is a callback on my ApplicationController:

around_action :wrap_in_transaction
def wrap_in_transaction
  ActiveRecord::Base.transaction(isolation: :repeatable_read) do
    yield
  end
end

It's that simple! Except... It's likely your tests may fail, because they also start a transaction, with a different isolation level.

So add this your your test_helper.rb / spec_helper.rb:

# Tests already use a transaction, this tries to nest with a distinct isolation level, which breaks. So skip
ApplicationController.skip_around_action :wrap_in_transaction

Closing words

Hope you learned something useful!

If you want to play with examples that are similar to the post and demonstrate the effects of the repeatable_read transaction, here is a self-contained ruby script.

What makes Ruby's blocks great

2022-02-09T19:00:00-05:00

In Ruby, we often talk about "blocks". While not unique to Ruby, few mainstream languages have something I would consider equivalent and, to be frank, I think they're missing out.

Just explaining to someone what's special about them can be tricky. I think many rubyists use blocks without realizing that they are different from what's possible in other mainstream languages.

This post is an attempt to explain what's great about blocks without being a verbose in-depth guide. It's written with non-rubyists in mind. I hope it can pique your interest.

Anonymous function with a nicer syntax

That's the first thing one may say to describe them, or the first thing that someone hearing about them will think of, and... that's a start. The nicer syntax is certainly an important part of what makes Ruby's blocks feel great to use, but there is more than just that.

Compared to anonymous functions, blocks are more powerful and more consistent with other standard constructs such as for loops. So much so that they have entirely replaced for loops in Ruby; you instead call a method and pass it a block.

Blocks managed to do that because they have more control over the flow of code than your regular anonymous functions, giving them as much power as a for loop.

To explain what I mean, let's work with a simple "for each" loop. Here is what a block looks like in Ruby.

To make it easier for non-rubyists, I'm using a style closer to other languages.

What we call a "block" goes from do to end.

Quick code explanation:

[1, 2, 3, 4].each() do |v|
  puts(v)
end

An Array literal, it "gives" an Array with those 4 values. Same as JavaScript

[1, 2, 3, 4]

Calls the method each (on the Array), passing it the block that follows the parentheses

.each() do ... end

The parameters the block accepts: one parameter called "v".

|v|

The content of the block, what will run when it is called. This prints the value to the console.

puts(v)

Other than the clean syntax for passing the block ("anonymous function"), this is nothing special. In javascript, this would be:

// Another syntax exists, but I think this is more universally recognizable
[1, 2, 3, 4].forEach(function(v) {
  console.log(v);
})

From this common ground, let's see how using blocks compare to anonymous functions by thinking of loops.

`break`

Most languages with loops allows you to exit early from them. Usually with a break keyword.

Think of the previous examples, but stopping (like break) after v == 3.

How do you do this with the forEach method in JavaScript? The simple answer is that you can't do it simply. You either switch to an actual for loop or use exceptions or some other workaround.

break cannot be used to exit an anonymous function. But in Ruby, in a block...

[1, 2, 3, 4].each() do |v|
  puts(v)
  if v == 3
    break
  end
end

break just works.

break exits from the function to which the block was passed (each in this case), so the block can stop early just like in regular for loop.

We'll talk more about break in a bit; it can do more, but I want to go over the simpler cases first.

`return`

How about returning from a function from within a loop? That's pretty common.

You, again, can't do this using anonymous functions in most languages. The return keyword would only return from the anonymous function and its caller would call it again for the next iterations.

But it's easy in Ruby with its blocks:

def my_func() # Just defining a function to return out of
  [1, 2, 3, 4].each() do |v|
    puts(v)
    if v == 3
      return 42
    end
  end
end

return just works, again!

When the code reaches the return, it's not the block which returns 42, it's actually my_func. return leaves the block, the call to each, and returns from my_func with the specified value. Just like return does in actual loops.

return can still useful be useful in an anonymous functions. It can return a value to be used, such as a map function or it can stop the current iteration to go to the next one. This is the equivalent of continue and next. So let's move over to these.

`continue` / `next`

In loops, we sometimes want to skip an iteration, just go to the next one. Most languages will have a continue or next keyword that can be used in loops.

Instead of stopping, let's skip the iteration where v == 3.

As mentioned in the previous section, JavaScript and most other languages can achieve this in anonymous functions using return, but they cannot use the standard continue or next:

[1, 2, 3, 4].forEach(function(v) {
  if (v == 3) {
    return;
  }
  console.log(v);
})

Ruby has next and it works in blocks exactly as one would expect in a loop.

[1, 2, 3, 4].each() do |v|
  if v == 3
    next
  end
  puts(v)
end

Pretty neat.

This is where the parallels with for loops end.

`next 42`

Blocks are used for more than just replacing a simple for loop. Let's switch to using map for our examples. For those unfamiliar, map is a for loop which also saves a return value for each iteration in an array and returns that array.

As an example, squares gets set to an array of the square (2nd power) of each number.

squares = [1, 2, 3, 4].map() do |v|
  # Ruby detail: the `next` is optional for the last expression, the `next` is implicit
  # Leaving it in for clarity
  next v ** 2
end

next can receive a value. It's what it will "return" to the method that called the block (map in this case). It really is just a return that stays at the block's level.

In JavaScript with an anonymous function, you would use return with a value.

squares = [1, 2, 3, 4].map(function(v) {
  return v ** 2;
})

`break 42`

In Ruby, break can also receive a value. Break-ing news, right? :)

# We add a secret override code... it's an example ok! suggest a better one in the comments
squares = [1, 2, 666, 4].map() do |v|
  if v == 666
    break [-666]
  end
  v ** 2
end

In addition to breaking out of the function that received the block (the map in this example), the function will return the value given to break. So in the above example, squares will be set to [-666].

Honestly, this is rarely used. Again, no equivalent here in JavaScript and most other languages.

These were the main things that make blocks in Ruby more than just anonymous functions. Still with me? Here is a little wrap up.

Building an intuition

With the right perspective, blocks' behaviors are quite intuitive.

When dealing with loops, you have 3 nested constructs interacting: a wrapping function, a loop statement and the loop's body; and you have 3 keywords to choose where the flow of the code goes.

return returns from the wrapping function
break leaves the loop statement
next / continue leaves loop's body

When dealing with blocks or anonymous functions, it's instead 3 nested "functions" that are interacting: a wrapping function, a called function and an anonymous functions (or block).

Ruby's blocks, let you use the same 3 keywords to choose where the flow of the code goes.

return returns from the wrapping function (ex: my_func)
break returns from the called function (ex: each, map)
next returns from the block

Quite consistent. But since we are talking about functions instead of statements (loop), return values are also involved. Allowing both break and next to provide a return value fits well in that model and is quite useful. The 3 keywords are basically return, but they have different targets.

More than just loops

I've been focusing on looping structures because those are common and simple to understand, but blocks are used for lots of things.

File.open("my_file.txt", "w") do |f|
  f.puts('x')
  f.puts('y')
  f.puts('z')
  # It is automatically closed when leaving the block
  # Including if you use return/break/next within
end

thr = Thread.new() do
  # Do stuff in your thread
end

Timeout.timeout(5) do
  # Code that will be interrupted if it takes more than 5 seconds
end

# (on a Hash, often called a Map or a Dictionary in different languages)
# The block is only called if "my_key" is not in the hash.
value = my_hash.fetch("my_key") do |key|
  # generate default value, maybe set it in the hash
end

# Ok, another loop because it's cute
5.times() do |i|
  # This block gets called 5 times, with `i` going from 0 to 4
end

Tool making

Programming is all about making tools from other tools. To me, blocks are a very neat one that fit seamlessly in the Ruby language and handle many roles. They really feel like a generalization of anonymous functions and I wish more mainstream languages would have them.

Try Ruby out

You can try Ruby from your browser at https://try.ruby-lang.org/. There is a small Ruby lesson built into the site, but it may feel too simple for more advanced programmers. Anyhow, it will let you type some Ruby and see the result.

You should avoid `includes` in Rails

2021-02-14T19:00:00-05:00

includes is the recommended way to load associations of your records eagerly in Rails. In fact, the Ruby on Rails guide for eager loading only mentions includes. However, there are other ways, and I want to argue that you should avoid includes.

Here's why:

includes makes it easy to introduce an odd bug
preload takes the same arguments as includes, but can't introduce the bug
When needed, eager_load also takes the same arguments, can introduce the bug, but makes it explicit

What bug? Let's show the introduction of an unexpected bug:

Say you have these records:

p = Post.create!
p.comments.create!(content: 'hello', spam: true)
p.comments.create!(content: 'world')

You want posts that have at least one comment marked as spam.

# distinct because joins can make duplicates
# I dislike using joins for this.
posts = Post.joins(:comments).distinct
            .where(comments: {spam: true})

How many comments in this array?

posts.first.comments.to_a.size

2, nothing special there.

You will need to display the comments of the posts, so you includes them.

How many comments are in the array?

posts.includes(:comments).first.comments.to_a

Only 1, the one with `spam = true`

What's the count?

posts.includes(:comments).first.comments.count

Back to 2!

What about size?

posts.includes(:comments).first.comments.size

Back to 1!

To be clear, the joins isn't needed for this to happen.

It was just to show a progression.

Post.includes(:comments)
    .where(comments: {spam: true})
    .first.comments.size
# => 1

Personally, I find that unexpected.

Imagine if the post is passed to a view or a helper, which uses the comments. It would only print the comments that matched the condition. Now if you try to debug from that helper, you would see that post.comments only has 1 comment.

Hopefully, you know that this is how includes (and eager_load, see below) behaves, so you may look up where the post comes from and figure it out. Good luck otherwise.

This is considered a feature. The consequences of doing conditions on eager loaded association are not in the guide, but they are in the middle of this section of the documentation.

I sometimes see this called "conditional eager loading", and the bug is doing it accidentally.

I consider the whole feature a maintenance burden. At least the guide doesn't recommend using it.

TL;DR: my recommendations

Things will get more technical in the next sections, so my condensed and straightforward recommendations are:

For new code, if you are only doing eager loading, use preload instead of includes. It does the same eager loading as includes, and takes the same arguments, but it ignores the conditions in the query. With it, things work as expected:

posts = Post.joins(:comments).distinct
            .where(comments: {spam: true})
posts.preload(:comments).first.comments.to_a.size #=> 2
posts.preload(:comments).first.comments.count #=> 2
posts.preload(:comments).first.comments.size #=> 2

If you need to order by an association, then eager_load is basically the only simple way to do so.
If you need a condition (a where) which uses an association, avoid includes, joins and eager_load.
Instead, I recommend my gem: activerecord_where_assoc. Here's an introduction to it.
It's made for this purpose, and will support many more use cases, such as:
- Recursive associations (parent/child)
- Polymorphic belongs_to
- Negative conditions (ex: posts without comments marked as spam)
- Multiple conditions on different records of the same association
Alternatively, there's another gem for this: where_exists

# Same as before, posts that have at least one comment marked as spam
Post.where_assoc_exists(:comments, spam: true)

If includes seem to work somewhere that preload doesn't, you're probably doing a condition on an association or ordering by an association. See the previous points for this.
For existing code, you can't mindlessly change all includes to preload, because some of it may rely on includes adding a JOIN to the query (the eager_load way), which happens when the query refers to the table of the included associations. So while it would be better to change everything to preload and sometimes eager_load, every such change must be tested.
If you see an includes with a references, then that's just a call to eager_load. At this point, just use eager_load to make your code shorter.

So don't risk includes doing the wrong thing. preload means simple eager loading without the booby trap; you should use it. Treat eager_load as a warning sign that this could be doing conditional eager loading and be careful around it.

Down the rabbit hole

If you want to understand why I make those recommendations, we'll have to get technical...

Eager loading means loading associations of multiple records before they are needed. This is done to reduce the number of queries executed, making execution faster.

There are actually 3 methods for eager loading in Rails:

preload: Executes one extra query per association being eager loaded. Same as includes usually does.
eager_load: Adds JOIN to the SQL query and load the association without doing an extra query. This also enables adding conditions on the table, which is the cause of the conditional eager loading bug from the introduction.
includes: Picks between preload and eager_load based on if there is a reference, in the query, to the table of an association that was passed to includes. This can be from where or from joins.
You may also specify an association with references to force the eager_load path, which is needed when your conditions are specified with a String instead of a Hash (which, again, causes conditional eager loading).

So out of the 3 methods, only one of them cannot trigger conditional eager loading: preload. It only does full eager loading, always the same way.

When is `eager_load` needed?

The main reason to use eager_load, that I have no alternative for, is ordering by an association's field.

# Ordering posts by created_at of last comment
Post.eager_load(:comments).order("comments.created_at DESC")

Maybe some use it to reduce the number of queries when they do eager loading. I don't think it really saves much, and there is a risk of slowing things down by making queries that are heavier.

Some may use it to actually do conditional eager loading. I still heavily disagree with that use case.

I've had to edit code that used this "feature" once...

You look at a method and it looks wrong; it can't be doing what it should be doing. It's using every project.users, not just those we want! When I did an interactive console there (binding.pry or byebug), I saw that users were missing from project.users.

Since I knew of this "feature", I started looking and, as expected, a condition on an includes was found... 3 method calls away from where the association was used, not a single comment to explain what is going on anywhere.

You should avoid code that looks wrong. Code that uses conditional eager loading looks wrong. In our case the overall module was already something that we wanted to rewrite from scratch, so this was just another reason to do so.

Other than ordering, I mostly see eager_load used to do a condition (a where) which uses an association. Let's dig into these.

`where` on an association with `eager_load`

It's a somewhat frequent need and there are many questions about this on stack overflow.

The bug from the introduction, accidentally doing conditional eager loading, started with such a need: "I want the posts that have comments marked as spam".

You may see a recommendation to use includes, and then have a condition on its table. This actually uses the eager_load path.

It looks like this:

# Please stop doing this :(
Post.includes(:comments).where(comments: {spam: true})
# which is equivalent to this; don't do this either
Post.eager_load(:comments).where(comments: {spam: true})

Again, this does conditional eager loading, which isn't what we asked for.

To be clear, the where on an association with includes / eager_load can be safe. But only if the association is a belongs_to. When it is, there are only 2 possibilities: either load the record and the associated belongs_to records, or don't load either. No conditional eager loading is possible.

But even when it's safe, there are risks:

Using includes / eager_load increases the chance for a mistake, where you or someone else just add another association to the existing eager loading call.
Every time a reader sees includes / eager_load, he may wonder if it is safe, or if there could be accidental conditional eager loading.

And as a tool, this isn't so great:

If you don't need the associated records, then eager loading them is wasteful.
Doesn't handle recursive associations (ex: parent/children)
Doesn't compose well
Looks potentially wrong when you know of the conditional eager loading "feature"

`where` on an association with `joins`

The next option is to use joins. It also has downsides.

It looks like this:

# Please stop doing this :(
Post.joins(:comments).where(comments: {spam: true})
# and stop doing this
Post.joins(:comments).distinct.where(comments: {spam: true})

Using joins like this is better than includes / eager_load since at least, there is no risk of conditionally loading an association. But there are still problems with it:

Doesn't handle recursive associations (ex: parent/children)
Requires a distinct to avoid duplicated records when used with has_many associations.
This can be unexpected if you're doing a more complex query than j ust fetching records.
Doesn't compose well

`where` on an association with Arel

Truth is, this need for a where on an association isn't something that ActiveRecord supports well. So leaving the ActiveRecord only solutions, you can do an actual EXISTS query with Arel. EXISTS is the SQL tool that is meant to do this type of condition, not JOIN.

It looks like this:

# An OK way, but error prone
Post.where(Comment.where("posts.id = comments.post_id").where(spam: true).arel.exists)

This composes much better with other tools because all it does is add a single WHERE clause to the query. It works as you would expect with or, not and with other conditions on the same association.

But there still are new downsides:

You must manually write condition to link the posts to the comments. It's easy to forget it, and I've seen StackOverflow answers that forgot to do so.
You won't get any error for forgetting, your query will just be wrong, which may not even be obvious if all you have is a little test data. Bonus: This can get extra tedious for polymorphic associations, where you also need to this check: foos.owner_type = #{Bar.base_class.name}.
If a condition was given when defining the association, you must also manually rewrite it.
Only the models are named in the code, not the association of interest. This makes the intent less clear, especially when non-trivial associations exist.
Extra work to handle recursive associations (ex: parent/children)
Quite a bit longer to write, and this is a short example.

Other than writing the whole condition manually, which would have all the problems of the Arel way, but be more verbose and more error-prone, I think we're out of built-in ways.

`where` on an association with activerecord_where_assoc

What I recommend for conditions based on associations is a gem I made just for this purpose: activerecord_where_assoc. It looks like this:

# Please consider doing this:
Post.where_assoc_exists(:comments, spam: true)
# Or using a scope such as is_spam:
Post.where_assoc_exists(:comments) { is_spam }

The query it generates is the same as the Arel example, with the same benefits and more. See for yourself:

It just adds a single where condition, so it composes well and works with or and with other conditions on the same association.
Handles recursive associations automatically (ex: parent/children)
Handles polymorphic belongs_to (includes and joins would simply refuse)
Easy to do a NOT of the condition (I.E.: where no comment is marked as spam) with where_assoc_not_exists.
Composes with other such queries, even on the same association, even with negations
Unlike Arel, this uses the association's name, so the intent is clearer.

So if you need to do this kind of condition, here are some references for my gem:

There's simply no way I could find to use builtin tools to have this query be clear, succinct and not booby trapped. Either live with the booby traps, write your own methods to do this cleanly, or use one of the gems written for this purpose:

Mine: activerecord_where_assoc
where_exists

Seriously, try any of them, it's liberating how simple this once complex task becomes.

But `includes` is everywhere

It is! Let's explore the reasons I can think of.

includes is the "smart" function out of the 3, it will pick the "right" strategy when needed.

Marketing-wise, this sounds like a good thing... Until you learn that the alternate path, eager_load, is not always what you want and it can cause bugs due to conditional eager loading.

For a long time, includes (and eager_load) were the only way to do a LEFT JOIN

The method left_joins was added in Rails 5.0. Before that, if you wanted one, you had to either do includes / eager_load, or write the whole "LEFT JOIN" yourself like this: joins("LEFT JOIN comments ON comments.post_id = posts.id"). The includes shortcut was often suggested.

includes has always been recommended, so most are familiar with it, and most recommend it.

Everything is against preload, even it's documentation makes preload sound like an alias for includes, and the Rails guide only mentions includes for eager loading data.

I think not enough people were both harmed by includes and aware that you can just specify preload and eager_load for that knowledge to spread.

Recap

Conditional eager loading:

includes and eager_load can accidentally eager load only part of an association, a good source of bugs.
Doing conditional eager loading voluntarily can be maintenance burden
If you do want conditional eager loading, using eager_load makes it a bit more obvious.

Conditions based on associations:

Using includes and eager_load for conditions based on associations can do conditional eager loading at the same time, you will get bitten by the bugs it can causes.
if you don't need to load the association, eager loading it is wasteful
Using specialized gems to do conditions based on association is safer, clearer and easier.

Order based on association:

includes and eager_load are the only simple way.
Using eager_load is explicit about the use case, and you don't need to also call references.

Regular old eager loading:

Just use preload

If you want to run the examples from this post, here is a self-contained ruby script.

MaxLapDev

The lesser known Rails race condition

Classical race condition

The lesser known race condition

But wait, there's more!

A solution

When to solve it?

Code to apply %everywhere

Closing words

What makes Ruby's blocks great

Anonymous function with a nicer syntax

break

return

continue / next

next 42

break 42

Building an intuition

More than just loops

Tool making

Try Ruby out

You should avoid `includes` in Rails

TL;DR: my recommendations

Down the rabbit hole

When is eager_load needed?

where on an association with eager_load

where on an association with joins

where on an association with Arel

where on an association with activerecord_where_assoc

But includes is everywhere

Recap

`break`

`return`

`continue` / `next`

`next 42`

`break 42`

When is `eager_load` needed?

`where` on an association with `eager_load`

`where` on an association with `joins`

`where` on an association with Arel

`where` on an association with activerecord_where_assoc

But `includes` is everywhere