Stock Reservation Response Never Checked in order_service - Team 177

[ybthummar]

Description

Imagine you're buying concert tickets online. You click "Reserve," but the system never actually checks whether the tickets were held for you. it just assumes they were and charges your card anyway. That's essentially what's happening here.
In create_order(), the code loops through each item and fires off a POST request to the product service's /reserve endpoint. But after making that call, it completely ignores whether the reservation actually succeeded. It blindly adds the item to the reserved list and keeps going. A 409 (Insufficient Stock), a 500 (server error), or even a 400 (bad request). All silently treated as success.

What happens step by step:

1. User orders 10 units of Product A (only 3 in stock)
2. The earlier stock check (lines 152–160) passes because it reads current stock — but another request could have consumed stock in between (race window)
3. The /reserve call returns 409 Insufficient Stock
4. The code doesn't check resp.status_code. it just appends to reserved anyway
5. The order gets created in the database as PENDING with total_amount calculated
6. The customer now has an order for 10 units that were never actually reserved
7. The SQS event fires saying the order was created. Downstream systems think it's real

In short = User get all 10 products, no matter those products are in stock or not.

Expected Behavior

After calling /reserve, the code should check resp.status_code. If it's anything other than 200, it should:

1. Roll back any items already reserved (release them)
2. Return a meaningful error to the caller

POST /api/v1/orders
→ 409: { "error": "Not enough stock for product 'Laptop'" }

Location

app.py

Impact

• Overselling: Orders get created for products that aren't actually reserved.
• Customers see a confirmed PENDING order, but there's nothing backing it in inventory. When they try to pay or you try to ship, the stock isn't there.
• No error is logged, no alert fires. Everything looks fine in the order table while inventory is slowly drifting out of sync.

Suggested Solution

With the perfect status logic of handling the checking process and comformation of order list at the same time.

[ybthummar]

I want to work on this issue.
Team 177