"Tree" structure for Stages, or Observers with executor?

[gal1ium]

Is your feature request related to a problem? Please describe.
Met a use case in which I have multiple existing mutational stages, and I want to catch/hook every mutated and crashing seed before it's directly added into the solution corpus, such as doing some calibration/minimization of the crashing seed first, which requires the executor to execute the seed more times.

Describe the solution you'd like
When existing mutational stages meet a crashing seed, it directly goes through observers/feedbacks and into the solution corpus. What if there could be a mechanism/stage (controlled by the user and combined with existing stages) to not only observe but re-execute it before adding into the corpus, such as minimization of the seed?
Maybe a "tree" structure for stages (or observer/feedback with executor) is for this scenario?

Describe alternatives you've considered
In the current design, having another separate stage to grab testcases from the solution corpus and do the calibration can achieve the similar goal. So not sure how necessary it is to change how much of the current structure.

[domenukk]

In general this seems like a useful thing to have.
One thing to keep in mind: For the InProcessExecutor a crash means that it will restart the fuzzer, and reload the current state - so we'll need to track the current action in the state before exiting. It could become complicated.
Maybe it's easier to add to the corpus, then, on restart, run the solutions calibration state first, keeping process in the metadata between restarts (and potentially remove them from the solutions corpus eventually)

[addisoncrump]

Do we have this now w/ IfStage and IfElseStage?

[tokatoka]

Do we have this now w/ IfStage and IfElseStage?

No.
I don't have any good idea on how to hijack the execution of one stage during its execution and transfer to another stage.

[domenukk]

Can we do this with hooks?