Fix error handling and serialization in workflow errors

[kochrac]

fix details is definitely initialized before we enter the begin block that contains the rescue, or avoid referencing it in the rescue without such a guarantee. The cleanest way without changing functionality is:

1. Assign details before the begin so it's initialized even if failure.application_failure_info.details itself raises.
2. In the rescue block, guard access to details.payloads.first.data so it doesn’t raise if details is nil or has an unexpected structure. Since this is only for logging, falling back to a safe placeholder string if details is unavailable preserves behavior and avoids new crashes.
3. Keep the rest of the logic (instantiating exception, setting message, logging) unchanged.

Concretely:

• Move details = failure.application_failure_info.details to just before the begin.
• Inside the rescue, compute serialized_error using a defensive expression that checks details and details.payloads.first exist before accessing .data, otherwise using something like nil or a descriptive string. This keeps the log informative without risking another error in the rescue handler.

---

In Ruby, it is not necessary to explicitly initialize variables. If a local variable has not been explicitly initialized, it will have the value nil. If this happens unintentionally, though, the variable will not represent an object with the expected methods, and a method call on the variable will raise a NoMethodError.

Incorrect Usage

In the following code, the call to create_file may fail and then the call f.close will raise a NoMethodError since f will be nil at that point.

def dump(x)
  f = create_file
  f.puts(x)
ensure
  f.close
end

References

RubyGuides You Need To Know About Nil
Ruby-Doc NoMethodError