Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Exceptions can be hard to catch in test environments

Aperta
#197 0 commenti 2 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
ruby
Ambito
backend, testing

Direzione di ricerca

Inizia da lib/temporal/workflow.rb, intorno al rescue di StandardError, e segui il modo in cui Temporal::Testing.local! esegue i workflow. Riproduci l'esempio della keyword mancante, quindi individua e documenta un comportamento dei test locali in cui le eccezioni del workflow emergono senza modificare la normale gestione dei workflow; il lavoro è completato quando il test espone l'eccezione con uno stack trace utile.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Ruby
Stelle
288
Fork
113
Merge medio
10g 15h
PR unite (30g)
2

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di coinbase/temporal-ruby

Tutte le issue di coinbase/temporal-ruby

Issue simili

Altre issue su Ruby

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.