Closed danila closed 1 year ago
From what you've said that sounds like a bug. I'll have to do a bit of exploring to see what I can figure out.
@AaronLasseigne thanks for looking into this! Since it sounds like a bug, I could also investigate this and suggest a possible fix in a PR, wdyt?
A PR would be great!
This is fixed in the 5.3.0 release. Let me know if you have any issues.
Hello there! I stumbled upon a behavior that I find unobvious. Although I'm not sure I cook errors the right way they are designed to be used. Please feel free to correct me if I'm wrong. And if not, I'll be happy to introduce missing (from my pov) logic.
I use errors in the following style:
errors.add(:base, "Activity is completed", code: "activity_completed")
So that I use thetype
part of an error as a holder for an error message, and then I add a code to the options hash. In case I use composition and want to merge errors of nested interaction with the errors from the current context, the nested error options are ignored, so I end up losing nested error codes. From what I see in the sources, the reason istype
aString
and thereforemerge_detail!
which considers options is not used during merging. Like that (execution happens inside interaction):And I expected that
errors.merge!(result.errors)
would have producedA possible workaround that would suit me could be an interface for
ActiveInteraction::Errors
which would allow pushing existing errors objects.I will be very grateful for the clarifications.