princemaple
Just want to share the bug I caused and spent too long debugging.
I got this order item that has amount (required amount) and amount_shipped on it. You know, sometimes shipping isn’t done in a single batch.
Instead of writing a plain and simple context function, I thought it was a good idea to use a changeset with an update_change to streamline the process and the client only has to supply a new value to amount_shipped, thus avoiding a controller action, a context function and potentially a virtual field.
So I ended up with something like this:
def changeset(order_item, %{amount_shipped: _} = attrs) do
order_item
|> cast(attrs, [:amount_shipped])
|> update_change(:amount_shipped, &(&1 + order_item.amount_shipped))
end
The atom key amount_shipped in pattern matching is just because this particular changeset clause is only used with processed data. Irrelevant here.
This approach worked relatively well, until some point where a weird bug was reported. Sometimes, the amount_shipped is not updated.
This took me way too long than it should have taken to figure out… The bug turned out to be simple, if 500 was already shipped and you ship another 500, this is not a “change” and does not trigger update_change.
I could have taken the chance to rewrite it back to plain and simple albeit more verbose solutions… 
but I ended up with this fix:
def changeset(order_item, %{amount_shipped: amount_shipped} = attrs) do
order_item
|> cast(attrs, [:amount_shipped])
# in case same amount
|> force_change(:amount_shipped, amount_shipped)
|> update_change(:amount_shipped, &(&1 + order_item.amount_shipped))
end
Not promoting the trick or anything. Just sharing some head-scratching fun I had.
Where Next?
Trending in Discussions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Elixir, Erlang & messaging conferences from Code Sync. Next up: ElixirConf US (10–11 Sep) & Code BEAM Europe (21–22 Oct), Haarlem + online.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 4- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
LostKobrakai
Tbh that sounds like the more appropriate solution to me. The customer is no longer submitting the schemas fields. They’re submitting deltas. The way to handle that would imo be validating their input based on a schema for the input. Then do the business logic of applying the deltas and use the result as the changes for the persisted data.
E.g. validating
:amount_shippedto be >= 0 has completely different meaning applied to the delta send by the customer than it has to the resulting total on the schema. Trying to conflate the two will imo only be a source of confusion in the future.A more viable shortcut could imo be an virtual fields for
:amount_shipped_deltavs the:amount_shippedtotal.princemaple
Yup, totally agree. A virtual field would be more appropriate.
It’s a low usage in-house project so I prioritized fun and experimenting with different solutions, instead of a simple and easy to understand one.
Over the years I had some good fun with update_change. Given that a field is never directly writable by a user, I have done things
update_change(:password, &Bcrypt.hash_pwd_salt/1), so I don’t have a virtualpasswordand a materializedhashed_passwordA lot of fun.
codeanpeace
That’s a fun bug, thanks for sharing!
Out of curisoity, could the
force_changetrick open the door to the opposite problem? For example, 500 was already shipped and user updates an unrelated field or “messes” with:amount_shippedfield without actually meaning to change it, then sees an unexpected doubling of:amount_shipped.To add to the point about deltas made by @LostKobrakai, tracking each delta would also be useful for auditability down the line. Overwriting
:amount_shippedmeans you won’t have the information necessary to retroactively support any feature requests to display amount shipped over time.princemaple
Hi, glad you found it interesting.
To answer this, I have to come back to quote my own text in the post first:
:amount_shippedand has no chance confusing with other fieldsThis is a very good point. I didn’t show everything here. I only showed
orderandorder-itemshere, there are actually associatedshippingandshipping-items. When ashippingis approved, it updates the items in its parentorderwith itsshipping-items. History can be constructed by querying all theshippingsrelevant to an order, and details are in their itemsAnd you probably guessed by now, each
order-itemis updated withamount_shippedfrom the accordingshipping-item’samount.