Reportar un error de software de forma efectiva requiere método, no talento. Un ingeniero de software comparte en su blog un proceso estructurado en tres fases —asumir el bug, documentarlo y verificar el arreglo— ilustrado con un caso real: un leak de ByteBuf en el SDK de Azure OpenAI que terminó resolviéndose en unas semanas.
La primera fase consiste en asumir que el problema puede estar en el propio código y dedicar tiempo a descartarlo. Si el error no es propio, conviene hacerlo determinista (forzando System.gc() en una reproducción, por ejemplo) y aplicar una bisección entre versiones para localizar exactamente en qué lanzamiento apareció el fallo. A continuación, se reduce el caso a un repositorio público mínimo, con versiones pineadas, que sirva como prueba reproducible y como test de regresión una vez desplegado el arreglo.
La segunda fase se centra en presentar el informe allí donde apunte la evidencia —en este caso, reactor-netty y, tras descartarlo, el SDK de Azure para Java— y en hacer trabajo de arqueología: revisar pull requests e issues anteriores que expliquen cambios recientes en el ciclo de vida de las conexiones. El informe debe contener versiones, historial, traza completa, logs saneados y el repositorio de reproducción, además de cualquier peculiaridad del entorno.
La fase final es verificar el fix de forma independiente. En el caso relatado, el maintainer Alan publicó un pull request un día después de responder a unas pocas preguntas, y la reproducción confirmó que el problema quedaba resuelto. El autor subraya que ninguna de estas tareas exige talento especial: solo tiempo, honestidad sobre lo que se sabe y lo que no, y empatía con la persona que recibirá el reporte.