4 ms·
I don't understand the problem. Or rather the design of their system. > The issue was that our system for weekly ad was having an issue where the ads needed to
by duckmysick 3y ago
I don't understand the problem. Or rather the design of their system.
> The issue was that our system for weekly ad was having an issue where the ads needed to 'clip' a coupon (read hit an api) for the discounted price to reach our cart calculations. However, the api that we used for managing the weekly ads was managed by an external vendor, and often when we queried their endpoint, the coupon field was returning empty when it shouldn't.
What's the authoritative source if I want to know that a product has a discount? The external vendor? If the coupon field is empty, doesn't it mean there's no discount? Unless it means there are two different fields: one for is_there_a_discount and another for coupon_id. Would there ever be an expected situation where there is a discount but not a coupon?
Or maybe the source is the internal system. In which case, can't the coupon be generated there?
Surely the source is not the frontend, right?
> Products already had the associated coupons.
From where? The source aside, does that mean the coupon_id never change or expire? If the same product has a different discount a few months from now, will it still use the same coupon?
Also, the apparent solution was hardcoding:
> so I completely hacked it, and replaced the api call service with a dumb function that returned hardcoded data copied from a production.
but a couple paragraphs before, the author mentioned it changes often:
> Because this data was missing a field, it required manual data entry to update it. However, this data changed in real time, so it was OFTEN out of date.
I don't understand how this was a showstopper before but isn't anymore. Or maybe these paragraphs talk about different things.
I don't question the bug fix or the author. I just can't grok it.
- KnobbleMcKnees 3y agoI believe the part about hard coding production data was referring to recreation of the bug, not implementing the solution which the author describes subsequently as "a couple of array functions". There's a fair bit of hand waving going on with technical details throughout but I don't think it's badly intended, more aimed at keeping the focus on the organisational issues described.
- javier123454321 3y agoHey, Author here. The source was our internal system, but the vendor was taking our id, converting it to their own id, and then serving us an ad with the coupon labeled formatted to their system. We were then using the vendor id to translate it back to ours. The coupons associated with the products were already from our system, so I could skip the entire translation back to our id. The manual overrides bit can be omitted, it's just how people in product were fighting a loosing battle of manually overriding the bad data. The hardcoding was in order to replicate the behavior, as it wasn't showing up in lower envs. It wasn't the fix, the fix was to just render data we already had. I didn't go too much into details because 1. I can't due to company policy, and 2. it's actually not the interesting bit. I was more making observation of the process.
- duckmysick 3y agoThanks, I understand it a bit better now. I realized later I focused on a side part of your post. My curiosity got the better of me. Hope the observed process is changed to something better.