Stock Reservation Response Never Checked in order_service - Team 177

Abierto
  • ¿Algo no está bien?
#6 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
python
Área
api, backend

Línea de trabajo

Comienza en app.py, en create_order(), incluida la comprobación de stock alrededor de las líneas 152–160, y sigue el POST al endpoint /reserve del product service. Verifica cómo se gestionan las respuestas de reserva y los elementos reservados previamente; se considera terminado cuando las respuestas distintas de 200 producen el error indicado, liberan las reservas anteriores y no crean ni publican el pedido como exitoso.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
3
Forks
8
Merge medio
1 h 6 min
PR fusionados (30 d)
3

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de keploy/ecommerce_sample_app

Todos los issues de keploy/ecommerce_sample_app

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.