For all actions, check availability, and set unavailable actions' weights to 0;
Pick a random action.
This means that all availability checks of all actions fire once per fuzzing iteration. Availability checks aren't as lightweight as they used to be, and so I would argue that this is a bad idea.
This issue proposes changing the flow to:
Call up weighted list of actions;
Pick a random action;
Check availability. If unavailable, set its weight to 0, and repeat. (It might be that we do something fancy with the weight on future cycles, ie giving it a decaying penalty.)
This then means that there are only as many availability checks as needed to find a valid action; this is at worst case all actions, but the average case will be much better.
Doing this paves the way for replacing availability checks with 'payload construction failure is not an error' type situations later on, if needed.
There might be some issues with doing availability this way, so I'll need to discuss it with everyone else on the project.
Currently, availability checks happen as follows:
This means that all availability checks of all actions fire once per fuzzing iteration. Availability checks aren't as lightweight as they used to be, and so I would argue that this is a bad idea.
This issue proposes changing the flow to:
This then means that there are only as many availability checks as needed to find a valid action; this is at worst case all actions, but the average case will be much better.
Doing this paves the way for replacing availability checks with 'payload construction failure is not an error' type situations later on, if needed.
There might be some issues with doing availability this way, so I'll need to discuss it with everyone else on the project.