If we decide that certain kinds of issue transmutations should be forbidden because of potential harmful effects they may cause, we'll need to decide how exactly to enforce that. It'll likely need to be done at runtime—for example either by ignoring the illegal modification and recording a secondary issue describing the violation, or perhaps by triggering a fatal error or something more severe.
Given that I plan to incorporate @x-sheep's suggestion and bypass sending .system
issues through this interface, I think the practical concern may be less to begin with. In general, if there is a non-.system
issue, it should be the result of some action the user took, so I'm not sure we should prohibit modifications of that class of issues.
Looking to the future, supposing we did implement something like a .memoryLimitReached
issue kind (again, hypothetical for example purposes only), my sense is that any behavioral effects of such an issue should be limited to reporting only. An Issue
isn't the same as an Event
: if, in the future, we implement some new feature which has important observable downstream effects on the overall testing system, more than just recording that something happened for later analysis, then such a feature should probably be represented as a distinct Event
kind, possibly in addition to an Issue
kind. This proposal is only intended to allow reacting to Issue
s, not any arbitrary Event
of which .issueRecorded
is but one kind.