Reproducir un fallo de lifecycle

1174. Identidad de la lección

Módulo

3.8 — Memoria y ciclo de vida

Lección

Reproducir un fallo de lifecycle

Tipo académico

Laboratorio de depuración

Tipo de esquema

práctica

Orden

2 del módulo

Tiempo estimado

60–75 minutos

1175. Objetivo de aprendizaje

Después de esta lección, podrás reproducir un fallo de lifecycle —ya sea un fallo observable en el proyecto actual o el escenario determinista de fallback— y documentarlo con pasos repetibles, instrumentación de sus límites y evidencia observable.

1176. Por qué importa

Un reporte como “a veces el objeto falla después de reiniciar” todavía no constituye evidencia útil de debugging de producción. Un registro útil separa el disparador, el límite del lifecycle, el estado observado y el estado esperado. De este modo, una hipótesis generada con AI puede ponerse a prueba en lugar de convertirse en un parche no verificado.

Si no puedes observar un fallo, debes registrarlo con honestidad. No lo fabriques modificando el procedimiento de reproducción hasta que algo se rompa.

1177. Conocimientos previos

Debes poder:

• identificar un recurso adquirido y su owner;
• explicar por qué la limpieza forma parte del lifecycle del recurso;
• distinguir una finalización normal de una ruta interrumpida o repetida;
• utilizar los logs o diagnósticos que ya existan en el proyecto.

Esta lección depende directamente de Dispose es una operación de lifecycle.

1178. Concepto central

Un fallo de lifecycle se vuelve accionable cuando conectas tres elementos:

1. Reproducción: una secuencia acotada de acciones que activa el fallo;
2. Instrumentación: observaciones colocadas en límites como adquirir, usar, liberar y reutilizar de forma inválida;
3. Evidencia: un registro que compara el comportamiento esperado con el real.

No empieces cambiando el comportamiento de producción. Primero determina si el fallo puede repetirse y qué límite podría incumplir el contrato de ownership. Si el proyecto no tiene un fallo observable de lifecycle, utiliza el fallback determinista que aparece más adelante. Ese fallback es un escenario de prueba controlado, no una afirmación sobre la historia del proyecto.

1179. Modelo mental: Cadena de evidencia de límites

Una hipótesis no es evidencia. “Probablemente se liberó el objeto dos veces” sigue siendo una hipótesis hasta que las observaciones en los límites la apoyen o la descarten.

1180. Ejemplo concreto

Imagina un handle temporal de interacción que se utiliza mientras el jugador inspecciona un objeto. Su contrato establece que debe adquirirse al comenzar la inspección, usarse solo durante la sesión activa, liberarse al terminar y no reutilizarse después de la liberación.

Un registro acotado podría indicar:

1. Empieza con el handle de interacción inactivo.
2. Comienza la inspección.
3. Termina la inspección.
4. Inicia otra inspección sin recargar la escena.
5. Repite el ciclo tres veces.
6. En el tercer ciclo, observa un error de uso inválido.

Los marcadores podrían mostrar acquire, release, acquire, release y, después, un intento de uso con la identidad anterior del handle. Esta evidencia concentra la investigación en el ownership y la reutilización al cruzar el límite de la inspección, pero todavía no demuestra una causa raíz ni una corrección.

1181. Flujo de trabajo AI-native

Usa AI para organizar la evidencia y generar hipótesis comprobables, no como sustituto de la reproducción.

1. Proporciona el contrato de lifecycle, los pasos de reproducción y los marcadores observados. No pidas primero una corrección.
2. Solicita tres explicaciones alternativas, cada una vinculada con una observación que pueda confirmarla o descartarla.
3. Pide la instrumentación mínima necesaria en los límites de adquisición, uso y liberación.
4. Aplica solo la instrumentación que puedas explicar e inspeccionar y ejecuta tú el escenario.
5. Devuelve la salida capturada y pide que se revisen las hipótesis. Clasifica cada afirmación como observada, inferida o sin probar.

La decisión sobre si el comportamiento observado coincide con el escenario definido y si la instrumentación alteró el timing o el comportamiento sigue siendo tu responsabilidad.

1182. Flujo de trabajo con Git

Antes de aplicar instrumentación de lifecycle, crea un checkpoint de recuperación en el repositorio existente. Registra su identificador para poder volver al estado previo si un cambio diagnóstico altera el comportamiento o el timing.

Cuando sea práctico, mantén la instrumentación separada de cualquier corrección permanente posterior. No combines los marcadores diagnósticos con una corrección en este ejercicio. Si no realizas una corrección posterior, registra que solo conservaste el estado de instrumentación.

1183. Error común

No interpretes una no reproducción como prueba de que el fallo reportado nunca existió, ni cambies los pasos solo para forzar un fallo. Una ejecución limpia registra un único resultado. Del mismo modo, un fallback determinista debe etiquetarse como escenario de prueba controlado y no puede presentarse como un incidente observado en el proyecto.

1184. Práctica guiada

Trabaja en el proyecto existente y elige un recurso u objeto con estado cuyo lifecycle sea visible. Hay dos rutas permitidas. Para completar la capacidad debes reproducir un fallo de lifecycle: un fallo del proyecto o el fallback determinista claramente etiquetado.

Parte A — Define el contrato

Escribe cuatro afirmaciones breves:

• Owner: quién o qué controla el recurso;
• Adquisición: cuándo pasa a ser válido;
• Fin del uso válido: cuándo deben dejar de usarlo sus consumidores;
• Limpieza: qué lo libera, reinicia o invalida.

Parte B — Intenta reproducir honestamente un fallo del proyecto

Escribe un procedimiento numerado que incluya un estado inicial definido, acciones exactas del jugador o de la prueba, condiciones de repetición o timing, comportamiento esperado y comportamiento real cuando se produce el fallo.

Ejecuta el mismo procedimiento al menos tres veces. Registra cada resultado como reproducido, no reproducido o intermitente. Si el resultado es intermitente, anota qué condiciones cambiaron entre ejecuciones. No modifiques el procedimiento solo para provocar un fallo.

• Si reproduces el fallo del proyecto, continúa con la Parte D usando ese fallo.
• Si no lo reproduces o no existe un fallo observable, registra el resultado y continúa con la Parte C, el fallback determinista. La no reproducción honesta no completa por sí sola la capacidad.

Parte C — Fallback determinista, solo para proyectos sin un fallo observable

Utiliza este escenario controlado únicamente cuando la Parte B no produzca un fallo observable de lifecycle. Selecciona un recurso de prueba descartable u objeto con estado cuyo contrato de lifecycle puedas inspeccionar. En una escena de prueba, un test harness o una ruta diagnóstica aislada, ejecuta esta secuencia:

1. Crea o adquiere un recurso de prueba nuevo.
2. Registra su identidad y su estado válido.
3. Libera sus recursos mediante su ruta normal de limpieza, llama a dispose si ese es el método real de la API, o reinícialo o invalídalo según corresponda.
4. Registra su estado liberado o inválido.
5. Invoca una operación que su contrato prohíba explícitamente después de la liberación.
6. Repite la secuencia completa al menos tres veces, con un recurso nuevo en cada ejecución.

El resultado esperado es que la operación inválida sea rechazada, se ignore de forma segura con un diagnóstico explícito o produzca la señal de fallo definida por el proyecto. Si no existe un diagnóstico para la reutilización inválida, añade la assertion o el marcador temporal más pequeño que permita observar la violación del contrato.

No llames a esto un incidente de producción ni afirmes que el proyecto ya lo mostraba. Etiqueta la evidencia como escenario determinista de fallback e identifica la transición inválida que ejercitaste deliberadamente.

Si no es seguro probar el recurso elegido después de la limpieza, no adivines. Elige otro recurso descartable o documenta que no pudiste ejecutar el fallback y no afirmes que completaste la capacidad.

Parte D — Instrumenta los límites

Antes de añadir o activar la instrumentación, crea y registra un checkpoint de recuperación en Git. Añade o activa marcadores diagnósticos mínimos para las transiciones relevantes. Cada marcador debe incluir, cuando esté disponible:

• nombre de la transición;
• identidad del recurso u objeto;
• identidad del owner o de la sesión;
• número de ejecución o ciclo;
• estado relevante, como válido, liberado o ya liberado.

No registres cada frame. Cuando sea práctico, mantén los cambios diagnósticos separados de cualquier corrección permanente posterior. No implementes una corrección permanente como parte de este ejercicio.

Parte E — Toma una decisión de debugging

Elige una decisión y justifícala en dos o tres frases:

• la reproducción del proyecto está suficientemente acotada para investigarla;
• el fallback determinista reprodujo la violación del contrato y está claramente etiquetado;
• la instrumentación se encuentra en el límite equivocado y debe moverse;
• la evidencia descarta la hipótesis inicial, por lo que hace falta otra hipótesis;
• el fallo sigue sin poder reproducirse, así que todavía no puedes declarar completada la capacidad y necesitas una variación controlada.

Parte F — Captura el registro de evidencia

Completa este registro:

Etiqueta del fallo:
Origen del escenario: reproducción del proyecto / fallback determinista / solo no reproducción
Estado inicial:
Checkpoint de recuperación antes de instrumentar:
Pasos de reproducción:
Comportamiento esperado:
Comportamiento real:
Ejecuciones y resultados:
Límite de lifecycle bajo examen:
Marcadores observados:
Hipótesis inicial:
Evidencia a favor o en contra de la hipótesis:
Instrumentación separada de una corrección final posterior:
Siguiente experimento mínimo:
Capacidad completada: sí / no

Una no reproducción del proyecto debe conservarse como tal. Un registro de fallback debe indicar que la transición inválida se ejercitó deliberadamente en una prueba controlada. No implementes una corrección permanente en este ejercicio.

1185. Validación y evidencia

1186. Ideas clave

• La reproducción convierte un síntoma impreciso en una condición de prueba repetible.
• La instrumentación de límites muestra transiciones y ownership sin generar logs indiscriminados.
• Un fallback determinista puede demostrar la capacidad cuando no existe un fallo observable en el proyecto, pero debe permanecer claramente etiquetado como escenario controlado.
• La no reproducción honesta es evidencia, pero no completa una capacidad que exige un fallo reproducido.
• Las hipótesis deben compararse con evidencia observable.
• La instrumentación diagnóstica debe mantenerse separada de una corrección permanente posterior cuando sea práctico.

1187. Siguiente lección

Siguiente: 3.9 — Assets. Llevarás esta disciplina de evidencia al siguiente módulo al evaluar la adquisición, el uso y la liberación de assets.

1188. Comprobación