Como desarrollador de Android que trabaja en una popular aplicación de remesas que admite más de 100 000 usuarios, es mi trabajo garantizar que la aplicación funcione sin problemas y que todos los problemas informados se resuelvan de inmediato. Estaba acostumbrado a recibir un ticket de soporte ocasional de usuarios que informaban problemas con la aplicación. Pero un día, recibí una avalancha de tickets de personas que no enviaban dinero a una región en particular a través de la aplicación. Esto era especialmente preocupante porque se acercaba la temporada navideña, una época en la que muchas personas confían en nuestra aplicación para enviar dinero a sus seres queridos.

Sabía que tenía que llegar al fondo de este problema lo más rápido posible. Así que recurrí a la sabiduría de Sherlock Holmes y comencé mi trabajo de detective. Pero como pronto descubrí, resolver este problema no iba a ser una tarea fácil. Iba a necesitar todas mis habilidades de detective, así como un poco de suerte, para localizar la causa raíz del error y hacer que la aplicación volviera a funcionar correctamente.

La puesta en marcha

Empecé reproduciendo el problema en mi propio dispositivo, tratando de enviar dinero a la región afectada. Efectivamente, la aplicación se congeló y mostró un mensaje de error que decía: "Error en la transacción. Vuelva a intentarlo más tarde". Intenté usar un generador de perfiles en Android Studio para ver si había algún problema de rendimiento que pudiera estar causando el problema. Sin dados, la aplicación funcionaba como se esperaba.

Rápidamente revisé los registros para ver si había alguna información que pudiera ayudarme a entender lo que estaba pasando. Desafortunadamente, los registros no fueron muy útiles. Mostraron que la aplicación estaba realizando las solicitudes de red habituales, pero no había indicios de qué estaba causando el problema. Sin embargo, parecía que se produciría un error cada vez que intentáramos realizar una solicitud POST al punto final de transactions pero solo para esa región específica. Parecía que no importaba lo que intentara; Parecía que no podía acercarme más a resolver el misterio.

A continuación, extraje el código más reciente y revisé la rama de producción para ver si alguna confirmación reciente podría ser relevante para el problema en cuestión. También intenté hacer solicitudes individuales usando Postman y noté algo peculiar. La solicitud devolvió un código de respuesta de 400 , lo que significa que era una solicitud incorrecta; esto normalmente significa que el cliente no está enviando toda la información requerida por el backend. Sin embargo, no pudo devolver un error significativo que detalla qué datos faltaban en la solicitud. Dado que esta solicitud funcionaba antes, parecía que el problema estaba en el lado del servidor.

Para probar esta teoría, utilicé un debugger para profundizar en el código. Establecí puntos de interrupción en puntos clave del código e intenté enviar una transacción nuevamente, esta vez prestando mucha atención a lo que estaba sucediendo debajo del capó. Verifiqué si la solicitud contenía todos los datos necesarios que requería el backend e incluso desconecté la solicitud y la respuesta. Por desgracia, todo fue como se esperaba, pero todavía recibía el error de solicitud incorrecta.

La trama se complica

Mientras continuaba con mi investigación, no pude evitar sentir que me estaba perdiendo algo. Parecía que debería haber una explicación obvia para el problema, pero no importa cuánto busqué, no pude encontrarla. Podría sentir ganas de burlarme de mí, de mi propio Moriarty, del error sin resolver.

Justo cuando estaba empezando a perder la esperanza, tuve una idea. Recordé que dos semanas antes de que comenzara el problema, el equipo de back-end había lanzado una actualización del código del lado del servidor de la aplicación. ¿Podría ser que la actualización estaba causando el problema?

Hice ping a los desarrolladores de back-end en Slack para ver si tenían alguna idea sobre el problema. Me dijeron que recientemente habían lanzado una actualización del código del lado del servidor, pero no estaban seguros de si podría estar relacionado con el problema que estaba experimentando. Actualmente estaban inundados solucionando otro problema y solo pudieron investigar el mío más tarde. Mencionaron que la actualización se había implementado gradualmente, y solo un pequeño porcentaje de usuarios la recibió al principio. Debido a una nueva política, nuestras implementaciones ahora se realizaron por etapas y los usuarios la recibirían durante un período de dos semanas. ¿Podría ser que la actualización haya causado el problema solo para los usuarios que la recibieron?

El momento de la bombilla

Rápidamente revisé los registros de Crashlytic de Firebase para ver si había alguna correlación entre el momento de la actualización y el momento en que los usuarios comenzaron a experimentar el problema. ¡Y efectivamente, encontré una pista!

Después de un poco de ida y vuelta con el equipo, se confirmó mi teoría. La actualización incluyó un cambio en la forma en que el servidor manejaba ciertos tipos de transacciones. Y resultó que el cambio estaba causando problemas específicamente para las transacciones en la región afectada. Luego de una mayor investigación, descubrí que el backend ahora requería que se incluyera un campo adicional en las solicitudes de transacción, un campo que anteriormente era opcional. Este cambio se realizó debido a las nuevas regulaciones en la región, pero desafortunadamente se apresuró, estuvo mal documentado y no se probó a fondo. Como resultado, el campo no se incluyó en las solicitudes de transacciones para la región afectada, lo que provocó que las transacciones fallaran.

No podía creerlo. Después de todo mi trabajo de detective, finalmente encontré la causa raíz del error. Había requerido mucha deducción al estilo de Sherlock y algo de pensamiento creativo, pero finalmente resolví el caso del dinero perdido.

Inmediatamente me comuniqué con el equipo de back-end para informarles lo que había descubierto. Se sorprendieron al saber que su actualización había causado el problema y se disculparon por el descuido. Acordamos una solución doble. El equipo de back-end lanzaría una revisión con un valor predeterminado para el campo ahora obligatorio, lo que permitiría a los usuarios realizar transacciones mientras tanto, mientras que el equipo de la aplicación móvil lanzó una versión actualizada de nuestra aplicación de Android que solicitaría esta información adicional.

Conclusión

Resolver este error fue una experiencia desafiante y gratificante. Me recordó la importancia de pensar creativamente y no tener miedo de probar diferentes enfoques al depurar un problema. Y al igual que el fuerte vínculo entre Sherlock y Watson, también me recordó el poder de la colaboración y el trabajo en equipo: sin la ayuda del equipo de back-end, quizás nunca hubiera podido resolver este problema.

Espero que esta historia de mi trabajo de detective sirva como un recordatorio para que otros desarrolladores estén siempre atentos a las pistas y que nunca desistan de resolver un problema desafiante. Como dijo una vez Sherlock Holmes: "Una vez que eliminas lo imposible, lo que quede, por improbable que sea, debe ser la verdad". Con eso en mente, sé que cualquier error se puede vencer, sin importar cuán complicado pueda parecer al principio.