select/race flattens activity errors into the winner's value instead of surfacing a failure
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- javascript, rust
- Área
- backend, distributed-systems
Línea de trabajo
Empieza por src/handlers.rs, especialmente por make_select_future y ScheduledTask::Select; después compara la ruta de error directo en handlers.rs y lib/duroxide.js con make_join_future. Ejecuta la reproducción de RaceBoom proporcionada e inspecciona los puntos de entrada race() / raceTyped(). Se considera terminado cuando una rama ganadora fallida no pueda confundirse con un valor exitoso y el comportamiento existente de select esté cubierto por una validación de regresión.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
When an activity participates in ctx.race() / ctx.raceTyped() and fails, the select resolves successfully with the branch's raw error string as its value instead of surfacing a failure. The orchestration receives { index: 0, value: "<error message>" } and has no way to distinguish a failed activity from a successful activity that legitimately returned that same string.
This is inconsistent with the SDK's own semantics elsewhere:
- A directly yielded activity that fails is delivered via
driveStepWithError→gen.throw(...)— the orchestration sees a thrown error (handlers.rsbuilds the step payload withisError,lib/duroxide.jscallsgen.throwwhenisErroris set). ctx.all()/ctx.allTyped()(join) deliberately preserves the distinction:make_join_futurewraps each branch as{ok: v}/{err: e}("Unlike make_select_future, this preserves the ok/err distinction so JS can tell success from failure").
Only select flattens. The comment in src/handlers.rs documents it as intentional:
/// Convert a ScheduledTask into a type-erased future returning a raw string for use in select.
/// Activity/sub-orch errors are flattened (Ok and Err both become the raw string value).
fn make_select_future(...) -> ... {
match task {
ScheduledTask::Activity { .. } => Box::pin(async move {
...
match future.await {
Ok(v) => v,
Err(e) => e, // <-- error becomes the winning *value*
}
}),
...
The same flattening applies to ActivityWithRetry, SubOrchestration*, and GetValueFromInstance branches.
Why this is a footgun
The failure is silent. Orchestration code like:
const winner = yield ctx.race(
ctx.scheduleActivity("CallModel", input), // may fail
ctx.dequeueEvent("cancel"),
);
if (winner.index === 0) {
const result = JSON.parse(winner.value); // error string flows in here
...
}
happily treats the error message as the activity's result. Any error-handling try/catch around the yield — which works correctly for the direct-yield form — never fires. If the activity's legitimate return type is a plain string, the two cases are indistinguishable even in principle.
We hit this in PilotSwarm while converting a directly-yielded long-running activity into race(activityTask, dequeueEvent(stopQueue)) for a stop-button feature: the conversion silently disabled the entire activity retry path until we noticed the flattening in the bridge source and added a shape-sniffing workaround (parse the value; if it isn't the expected JSON payload, re-throw it as an error). That workaround only works because our activity returns structured JSON, not strings.
Repro
runtime.registerActivity("Boom", async () => { throw new Error("kaboom"); });
runtime.registerOrchestration("RaceBoom", function* (ctx) {
try {
const winner = yield ctx.race(
ctx.scheduleActivity("Boom", null),
ctx.scheduleTimer(60_000),
);
// Reached with winner = { index: 0, value: "kaboom" } — no throw.
return `unexpected success: ${JSON.stringify(winner)}`;
} catch (err) {
return `caught: ${err.message}`; // never reached
}
});
Expected (to match direct-yield semantics): the catch fires, or the winner carries an explicit error marker.
Actual: the orchestration completes with unexpected success: {"index":0,"value":"kaboom"}.
Possible fixes
- Throw into the generator when the select winner is a failed branch — consistent with the direct-yield contract. (Losing branches are already cancel-requested; only the winner's disposition changes.)
- Preserve the marker like join does: resolve select with
{ index, ok }/{ index, err }(or{ index, value, isError }). Breaking change for existing callers, but the current shape is unreliable anyway. - At minimum, document the flattening prominently on
race()/raceTyped()in the README and JSDoc — today it's only visible in a Rust source comment.
Option 1 seems most consistent; option 2 is more expressive if you'd rather races never throw.
Environment
- duroxide-node 0.1.27 (npm), also verified against current
mainsources (src/handlers.rsmake_select_future/ScheduledTask::Selecthandling) - macOS arm64, Node 20+
- Lenguaje dominante
- JavaScript
- Estrellas
- 36
- Forks
- 20
- Merge medio
- 20 h 52 min
- PR fusionados (30 d)
- 4
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de microsoft/duroxide-node
-
bug
Dificultad 3/5 1-2 días Aptitud para principiantes 65/100
microsoft/duroxide-node#19 ·
-
bug
Dificultad 4/5 3-5 días Aptitud para principiantes 58/100
microsoft/duroxide-node#18 ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 28/100
microsoft/duroxide-node#16 ·
Todos los issues de microsoft/duroxide-node
Issues similares
-
Link Checker ReportAbiertoautomated issue report
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
0. to triage bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
sindresorhus/eslint-plugin-unicorn#3825 ·
Los mantenedores suelen responder en 1 día