Bug: Idempotency Key Not Checked Before Processing in order_service

[kushpatel2601]

Fix: Check Idempotency Key Before Processing in order_service

Team 072

---

Problem

The POST /api/v1/orders endpoint supported an Idempotency-Key header to prevent duplicate orders, but the key was only enforced at the database INSERT level via a UNIQUE KEY constraint.

This meant that on every duplicate/retry request, the full order pipeline still executed:

• ❌ User Service was called
• ❌ Product Service was called
• ❌ Stock was reserved again for all items
• ❌ DB INSERT failed with a unique key violation
• ❌ Reserved stock was rolled back — adding unnecessary load and a race condition window

In a production environment with retrying clients or flaky networks, this could cause inventory to be incorrectly decremented on every duplicate request before being rolled back.

---

Solution

Added an early database lookup for the Idempotency-Key at the very start of create_order(), before any external service calls are made.

If the key already exists in the database, the endpoint now immediately returns the original order's response — a true no-op with zero side effects.

---

Changes

File	Change
order_service/app.py	Added early idempotency key check inside create_order() before User/Product service calls

---

Testing

To manually verify the fix:

1. Start all services:

   docker compose up -d --build
   

2. Login to get a token:

   curl -X POST http://localhost:8082/api/v1/login \
     -H "Content-Type: application/json" \
     -d '{"username": "admin", "password": "admin123"}'
   

3. Create an order with an idempotency key:

   curl -X POST http://localhost:8080/api/v1/orders \
     -H "Authorization: Bearer <token>" \
     -H "Idempotency-Key: test-key-001" \
     -H "Content-Type: application/json" \
     -d '{"userId": "<user_id>", "items": [{"productId": "<product_id>", "quantity": 1}]}'
   

4. Send the exact same request again with the same Idempotency-Key.

5. ✅ Expected: Second request returns the same order id and status instantly — stock is not reserved again.

6. ✅ Verify stock count has not changed after the duplicate request.

---

Checklist

• Bug identified and root cause confirmed
• Fix applied only to order_service/app.py
• No other files modified
• Fix is backward compatible — requests without an Idempotency-Key are unaffected
• Early return uses correct HTTP 200 status (idempotent success, not a new creation 201)
• Tested manually against running services
• Reviewed by a team member

Closes #10 ;

[kushpatel2601]

Can you please review this PR and approved.