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

Exceptions can be hard to catch in test environments

Abierto
#197 0 comentarios 2 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
ruby
Área
backend, testing

Línea de trabajo

Comienza en lib/temporal/workflow.rb, alrededor del rescue de StandardError, y sigue cómo Temporal::Testing.local! ejecuta los workflows. Reproduce el ejemplo de la keyword ausente y, a continuación, determina y documenta un comportamiento de las pruebas locales en el que las excepciones del workflow afloren sin cambiar el manejo normal de los workflows; se considera terminado cuando la prueba expone la excepción con un stack trace útil.

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

Descripción

Cool library, and thank you for your hard work on it! I'm trying to help improve it through this feedback, and would be willing to open a PR if there's guidance provided on desirable compromises or solutions.

The way that Temporal::Workflow rescues StandardError makes catching exceptions in tests hard.

Take this spec as an example:

$global_var = 0

class HelloWorldWorkflow < Temporal::Workflow
  def execute(arg1, required_key:)
    $global_var += 1

    nil
  end
end

describe HelloWorldWorkflow do
  it "doesn't allow exceptions to surface very easily" do
    Temporal::Testing.local! do
      Temporal.start_workflow(HelloWorldWorkflow, "foo", required_key: "bar")

      expect($global_var).to eq(1)

      Temporal.start_workflow(HelloWorldWorkflow, "foo") # incorrect arguments

      expect($global_var).to eq(2)
    end
  end
end

The result is:

expected: 2
     got: 1

(compared using ==)

Yes, I can see in the logs that an exception is logged, but I feel like in tests raising exceptions should be the rule. Any number of things can break downstream within a workflow, and sometimes (when not directly testing the unit that is the workflow) it's useful to call a thing, and not have to make an assertion that it didn't log an exception -- if that makes sense. Rescuing StandardError is heavy handed in the tests, because allowing those to raise is way more useful in identifying any issues.

To address this I've wrapped the base class with my own, so I can re-raise the exception in a way that Temporal doesn't try to handle. I'm wondering if Temporal::Testing should take this into consideration and not rescue any exceptions when executing the workflow locally in tests.

class ApplicationWorkflow < Temporal::Workflow
  def execute(*args, **kwargs)
    perform(*args, **kwargs)
  rescue => e
    raise(Exception, e.message) if defined?(Temporal::Testing) && Temporal::Testing.local?
    raise(e)
  end
end

class HelloWorldWorkflow < ApplicationWorkflow
  def perform(arg1, required_key:)
    $global_var += 1

    nil
  end
end

And the more useful result now includes the exception and stops the execution of the spec, which is what would be most helpful.

Exception: missing keyword: :required_key

It's still not the best solution though because it now has two rescues and pollutes the stack trace.

Lenguaje dominante
Ruby
Estrellas
288
Forks
113
Merge medio
10 d 15 h
PR fusionados (30 d)
2

Guía de contribución

Abrir la guía de contribución

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 coinbase/temporal-ruby

Todos los issues de coinbase/temporal-ruby

Issues similares

Más issues de Ruby

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.