Timer timing issue
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Error
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- ruby
- Área
- backend, distributed-systems
Línea de trabajo
Comienza con state_manager.rb y el bucle de procesamiento de eventos history_window descrito en el issue. Reproduce el escenario del workflow en el que la finalización de sleep y el disparo del temporizador llegan en un único lote del historial, y compara el comportamiento actual con el comportamiento citado de los SDK de Java y Rust. El issue todavía no tiene una implementación acordada ni una definición de terminado.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
temporal-ruby Timer timing issue
Scenario:
- Timer started (30 minutes)
- Sleep started by workflow code (15 minute)
- Worker goes down
- Sleep ends
- Timer fires.
- Worker comes back up
- Worker receives a history containing the sleep finishing followed by timer firing.
The workflow thus receives two TIMER_FIRED events in its history at once. Now what should happen?
What’s happening in temporal-ruby today
It processes the timers in order. Sleep first, then the other timer. The workflow completes first, and it’s not allowed to do anything after the workflow has completed. Thus, if the timer issues a command, the task will fail with Temporal::WorkflowAlreadyCompletingError.
Attempted solution
My first attempt was to early-out in state_manager.rb
history_window.events.each do |event|
apply_event(event)
break if if workflow_finished?
end
This fixed my problem and is logical; the workflow will execute the same as it would have if the worker had never gone down. But, it will silently drop events.
I asked Maxim what other SDKs do…
Other SDKs’ behaviors
According to Maxim:
Temporal processes new events in batches. One batch per workflow task. It applies all the events before running workflow code. So in case of Java or Go, for example the Futures that correspond to timer will be set to ready before running any workflow threads. This way workflow can check if any of these Futures are ready to decide what to do next.
Signals have similar properties, but they use callbacks in Java and some other SDKs. Temporal SDK schedules callback threads before running workflow threads. This way workflow cannot complete before the callback threads were called.
Then in case of Java SDK it is going to make the main workflow thread eligible to run. But it still will run only after all other threads executed and all other Futures resolved.
Without this functionality you guaranteed to lose signals if they are delivered as callbacks.
Rust core does the same
Java implementation - we can a see that callbacks (timer in this case) have a higher priority than the main thread (which is awoken by the sleep in this case).
What now?
Changing temporal-ruby's behavior is obviously somewhat tricky and would cause version changes if not done in a version-safe way. We might take this fix on but want to work with the community.
- Should we fix this?
- Implementation suggestions for the fix itself?
- Version safety. I'm guessing we should add a configuration that changes this behavior that folks can opt into.
- Lenguaje dominante
- Ruby
- Estrellas
- 288
- Forks
- 113
- Merge medio
- 10 d 15 h
- PR fusionados (30 d)
- 2
Preparar el entorno
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 coinbase/temporal-ruby
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
coinbase/temporal-ruby#361 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
coinbase/temporal-ruby#341 ·
-
Emitting Metrics for PrometheusAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
coinbase/temporal-ruby#328 · 1 comentario ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
coinbase/temporal-ruby#326 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
coinbase/temporal-ruby#324 · 3 comentarios · 2 reacciones ·
Todos los issues de coinbase/temporal-ruby
Issues similares
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 95/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
GitHub docs are outdatedAbiertoL: javascript T: bug 🐞
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
dependabot/dependabot-core#16397 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
TheOdinProject/curriculum#31423 ·
Los mantenedores suelen responder en 1 día