Los errores que casi rompen mi API y cómo los solucioné - Episodio 28

🔥 "Todo iba perfecto… hasta que rompí la API" 🔥

Creía que mi API estaba lista.

A ver, tenía las rutas bien definidas, la base de datos configurada y todo parecía funcionar en mi entorno local.

Pero justo cuando intenté probarla en el servidor, todo se vino abajo.

Y eso se traduce en modelos que desaparecían, puertos bloqueados y errores que no tenían sentido.

Como te podrás imaginar... lo que parecía una simple prueba terminó siendo una pesadilla técnica.

Si alguna vez te has peleado con errores que parecen sacados de una película de terror, este post es para ti.

Y por eso hoy te contaré cómo sobreviví y qué aprendí en el proceso. 💥

Los errores que casi rompen mi API y cómo los solucioné. 📅 Diario de un SaaS

Pensé que tenía todo bajo control.

Esa falsa sensación que sientes que lo tienes todo controlado....

¿Sabes?

Pues bien, ya sabes que la API estaba corriendo sin problemas en mi entorno local...

Es decir, las rutas respondían correctamente y la base de datos estaba bien configurada.

Todo parecía listo para el siguiente paso... hasta que decidí probar en el servidor.

Ahí empezó el caos. 😅

Lo que debía ser una simple verificación de endpoints...

Fue el acabose!

O sea, se convirtió en una lucha contra errores misteriosos, puertos ocupados y modelos que simplemente desaparecieron del sistema.

En este post te contaré cómo solucioné cada uno de estos problemas y qué aprendí en el camino.

Porque, créeme, subestimar un "error tonto" puede hacer que nada funcione.

1️⃣ El temido "User is not defined" 😱

Si has ido siguiendo esta aventura, sabrás que todo estaba en su lugar...

Es decir, los modelos de base de datos definidos en SQLAlchemy, también las migraciones aplicadas....

Y la API lista para recibir peticiones.

Pero al intentar registrar un usuario, Flask me lanzó un error demoledor:

NameError: name 'User' is not defined

📌 Motivo del error:

El orden de importaciones en Flask es clave.

Y otras, esto lo había vivido ya antes, pero el hombre es el único animal que se tropieza con la misma piedra (mínimo) 2 veces.

O sea, si los modelos no se cargan antes de la instancia de la base de datos (db), simplemente no existen.

💡 Solución:

Moví la definición de db = SQLAlchemy(app) al inicio del archivo y...

¡Todo volvió a funcionar! 🚀

2️⃣ Errores en /login y /register: Modelos invisibles 👻

Pasé a probar los endpoints de autenticación (/login y /register).

Así que introduje credenciales en Postman y... error 500.

Me cagué en todo porque en teoría antes funcionaba...

Pero claro, el traceback indicaba que User.query.filter_by(email=data['email']).first() fallaba porque User no existía en la sesión de SQLAlchemy.

📌 Motivo del error:

Flask, cuando se ejecuta con debug=True, puede crear dos instancias separadas de la aplicación, generando inconsistencias en la base de datos.

💡 Solución:

Agregué app.app_context() al inicio del script:

if __name__ == '__main__':
    with app.app_context():
        db.create_all()
    app.run(debug=True)

Esto aseguró que los modelos fueran detectados correctamente. 🔥

3️⃣ La pelea con Flask y los puertos ocupados 🔥

Ya con la API funcionando, intenté lanzar el servidor:

flask run --host=0.0.0.0 --port=5000

Pero en lugar del mensaje "Running on http://127.0.0.1:5000/", recibí otro golpe inesperado:

OSError: [Errno 98] Address already in use

📌 Motivo del error:

Flask no podía iniciar en el puerto 5000 porque ya estaba en uso (probablemente un proceso zombie de una ejecución anterior).

💡 Solución:

Para liberar el puerto, ejecuté:

sudo lsof -i :5000  # Identificar el proceso que usa el puerto
kill -9 <PID>       # Matar el proceso

También agregué la opción --reload para evitar procesos huérfanos en futuros cambios:

flask run --reload

Resultado:

la API corrió sin problemas y aprendí que antes de lanzar el servidor, mejor revisar si el puerto está ocupado. 😅

🔎 Lecciones aprendidas

1. No subestimes los errores tontos: Muchas veces, lo que parece un fallo grave es solo un descuido en las importaciones o en la estructura del código.
2. Siempre usa app_context() con SQLAlchemy: Especialmente en Flask, para evitar que los modelos desaparezcan misteriosamente.
3. Los puertos ocupados son traicioneros: Un simple lsof -i :5000 puede ahorrarte horas de frustración.
4. Depuración paso a paso: Cuando algo falla, revisa el traceback con calma. La solución suele estar en los primeros errores, no en el final del log.

⏭️ Próximos pasos

Bueno... y tú qué?

Si te ha pasado algo similar?

Cuéntame en los comentarios:

¿cuál fue el error más absurdo que casi rompe tu API? 💬

Si quieres conocer otros artículos parecidos a Los errores que casi rompen mi API y cómo los solucioné - Episodio 28 puedes visitar la categoría Proyecto-IA.