Dylan Thacker-Smith

Yes, I think this should just be a part of active record. Ideally, `changed_attributes` would return the same thing as transaction_changed_attributes does in an after_commit callback.

If there are multiple saves in a transaction, then `saved_changes` will only return the changes from the last save, which can cause changes to be missed when using an after_commit...

Here are the test failures I get from using `saved_changes`, which shows cases which it doesn't cover. ``` # Running: ..F...FFF Finished in 0.067143s, 134.0423 runs/s, 148.9359 assertions/s. 1) Failure:...

Once we fix this behaviour, we should expose it under the name `committed_changes` ~~and raise if the method is called outside of an after_commit callback~~. We could deprecated `transaction_changed_attributes` and...

> raise if the method is called outside of an after_commit callback Actually, we may want to be able to get the transaction changes for another record during an after_commit...

The behaviour should probably be consistent with active record's `changed_attributes`, which seems to omit changes to attributes that were changed back. So it looks like this is a bug.

A timeout can be used to interrupt liquid rendering.

> Liquid does not accept `{% endraw{% f %}` as a valid `endraw` tag but accepts `{% endfor{% f %}` for `endfor` tags. This is because the second capture group...

There are trade-offs to having one or the other. Grouping related filters or tags by category helps with discovery when the reader doesn't know what is available. On the other...

Good point about redirects. It looks like we can use anchor redirects. For instance, I tried changing the https://shopify.github.io/liquid/tags/ redirect to instead redirect to https://shopify.github.io/liquid/tags/control-flow/#unless locally as a proof of...