Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Bug]: waitForCondition exhaustion can produce FAILED invocation without ErrorObject

Abierto
  • ¿Algo no está bien?
#634 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java
Área
backend, testing

Línea de trabajo

Empieza por WaitForConditionOperation.handleCheckFailure(), ChildContextOperation.handleChildContextFailure() y DurableExecutor.buildErrorObject(), y después ejecuta la reproducción síncrona de runInChildContext con LocalDurableTestRunner. Añade los fallbacks para errores nulos y una prueba de integración que cubra el agotamiento del número máximo de intentos. Se considera terminado cuando el paso, el contexto hijo y la invocación raíz están todos en FAILED con detalles del error.

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

Descripción

bug java pkg:sdk
Expected Behavior

When waitForCondition exhausts its configured attempts, the SDK should:

  1. Checkpoint the WaitForCondition step as FAILED with a non-null ErrorObject.
  2. Checkpoint an enclosing synchronous child context as FAILED with a non-null ErrorObject.
  3. Return a root DurableExecutionInvocationOutput with Status=FAILED and a non-null ErrorObject.

This ensures replay preserves useful diagnostics and any service/emulator consuming the invocation result can reliably record the execution as failed.

Actual Behavior

The built-in wait strategies throw WaitForConditionFailedException(String), whose DurableOperationException state has a null ErrorObject.

That null propagates through the failure path:

  • WaitForConditionOperation.handleCheckFailure() reuses DurableOperationException.getErrorObject() without a null fallback.
  • ChildContextOperation.handleChildContextFailure() does the same.
  • DurableExecutor.buildErrorObject() returns DurableOperationException.getErrorObject() directly, even when it is null.

The final invocation output can therefore be equivalent to:

{
  "Status": "FAILED"
}

The Java LocalDurableTestRunner preserves the FAILED status, but the error is absent. When used through SAM Local, this combines with an emulator bug that currently converts FAILED with no error into ExecutionSucceeded.

Steps to Reproduce

Use a synchronous child context containing a condition that never stops polling:

var runner = LocalDurableTestRunner.create(String.class, (input, ctx) ->
        ctx.runInChildContext("child", String.class, child ->
                child.waitForCondition(
                        "poll",
                        String.class,
                        (state, stepCtx) -> WaitForConditionResult.continuePolling(state),
                        WaitForConditionConfig.<String>builder()
                                .waitStrategy(WaitStrategies.fixedDelay(
                                        2, Duration.ofSeconds(1)))
                                .build())));

var result = runner.runUntilComplete("test");

The local runner reports FAILED, but the root error is absent. Running the equivalent handler through SAM Local can produce this history:

StepFailed (WaitForCondition)
ContextFailed (RunInChildContext)
InvocationCompleted
ExecutionSucceeded
SDK Version

2.1.0; the behavior is also present on current 2.1.1-SNAPSHOT / main as of 2026-08-19.

Java Version

17

Is this a regression?

No known working version.

Last Working Version

N/A

Proposed Fix

Always fall back to serializing the thrown exception when an SDK exception has no embedded error:

if (e instanceof DurableOperationException operationException
        && operationException.getErrorObject() != null) {
    return operationException.getErrorObject();
}
return ExceptionHelper.buildErrorObject(e, serDes);

Apply equivalent null fallbacks when checkpointing failures in WaitForConditionOperation and ChildContextOperation, so operation history and replay also retain the error.

Add an integration test for max-attempt exhaustion inside synchronous runInChildContext that asserts:

  • the step is failed with error details;
  • the child context is failed with error details;
  • the root invocation is FAILED with an error.
Related Issue

The SAM Local emulator status-handling defect exposed by this null error is tracked in aws/aws-durable-execution-sdk-python#656.

Lenguaje dominante
Java
Estrellas
28
Forks
15
Merge medio
2 d 7 min
PR fusionados (30 d)
42

Preparar el entorno

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 aws/aws-durable-execution-sdk-java

Todos los issues de aws/aws-durable-execution-sdk-java

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.