The Thank-You Email That Only Thanked Part of the Order

Bakery Buddy has an automation called Customer Reviews. Once an order is picked up, it drafts a short thank-you email naming what the bakery made and asking for a review. It's one of the smallest, most human things the app does. For months, on any order with more than one line item, it thanked the customer for less than they actually bought.

Where that sentence actually comes from

Every automation email describing an order pulls from one column, orders.description. It reads like a summary of the order. It isn't one. It's a copy of the note on the first line item, written once when the order was created and never touched again after that.

On a single-item order, "first line" and "the whole order" are the same thing, so nothing ever looked wrong. Checked against Marin's real order history, orders.description matches that first line item byte for byte on 610 of 621 orders that have line items at all: 98.2%. The two values agree often enough that there was never a reason to suspect one wasn't standing in for the other.

The gap only opens on an order with more than one line, and that's not a rare shape of order. 139 of 348 completed orders in the last year, 40%, had more than one line item. Two out of every five review emails were describing a fraction of what actually shipped.

What that looked like on a real order

Order 12443 totaled $2,400: a two-tier carrot cake, 250 sugar cookies, 50 gluten-free cookies, a batch of cupcakes, and delivery. The Customer Reviews email went out and thanked the customer for the carrot cake. $445 of $2,400.

Order 12431 was simpler and wrong in a different way. It was two full cakes for the same event, a princess cake and a Minnie Mouse cake. The email named one of them.

Neither of these read as a glitch. Both emails came out as complete, warm, well-punctuated sentences. Nothing about them looked broken. They were just wrong about what the customer paid for, in a message whose entire job is to sound like Bakery Buddy paid attention.

Why nothing caught it

Typecheck passed. Lint passed. The build passed. All 33 end-to-end specs stayed green the whole time this was live, and none of that is a gap in the tests. orders.description is a real, populated, correctly typed string column, and every automation that read it got back exactly the value it asked for. The bug was never in the code that reads the column. It was in the assumption that the column means "the order," when it has only ever meant "the first line of the order."

A build can't catch a field that's well formed and also incomplete. The only way to catch this one is to read the email next to the order it's describing, on a real order with more than one line.

The fix, and where it still isn't fixed

The real fix doesn't touch orders.description at all. Changing what that column means would ripple into order intake and the FreshBooks sync, and neither of those needed to change. Instead, automations now read order_line_items directly, drop the Delivery and Rush Fee rows nobody should be thanked for, and build the sentence from the full list of what was actually made. orders.description still exists and is still read, but only as a fallback for older imported orders that have no line-item rows at all.

One part of the app had already solved this correctly before the review email bug was ever found. The pricing comparisons Buddy shows when a baker prices a new order already read line items directly, for the same reason, well before this fix landed. That earlier fix never got carried anywhere else in the codebase, which is the part actually worth remembering.

• src/lib/social/orderFacts.ts, which writes the cake caption used on social posts, still reads description alone.
• src/lib/automations/cakeLabel.ts reads description alone and narrows even further, to only its first line.
• src/lib/ai/attentionOrders.ts still reads description alone too.

Three more places quietly describing part of an order, right now, in the same codebase that already knew better in two others.

What generalizes past cake

If a field in your data model is a copy of something else, taken once and never revisited, ask what happens the moment the thing it was copied from stops being singular. A "first item" summary and a "the whole order" summary are the same string on every simple case you'd test by hand, and a different one on every case a customer actually notices. The fix that matters is rarely fixing the field itself. It's finding every place that quietly assumed the field meant more than it did, and there is usually more than one, because the first fix only teaches the file it landed in.

If anything in your product summarizes something with more than one part to it, go find where that summary gets built, and check whether it's reading everything or just whatever happened to come first.