Question: Why are group proposals which execute immediately not expired after a period of time instead of immediately pruned?

[minxylynx]

Summary of Question

Why are group proposals which execute immediately not expired after a period of time instead of immediately pruned?

Version

0.46.6

Summary

I understand not wanting to hold executed group proposals in state for longer than needed. However, right now, if a SubmitProposal request is processed with the EXEC_TRY option, and it passes, in one fell swoop you:

1. create the proposal
2. add the automatic vote
3. tally said vote and weight, and set on the proposal record
4. and, if it passes, execute
5. and, if it succeeds the execute, set status to success on the proposal record
6. and then prune the proposal record, and the votes and tally along with it

The proposal never even hits state at height, so it becomes essentially unqueryable.

On top of that, the events that are emitted are essentially worthless when trying to reconstruct what happened during the above scenario. (2) is especially troublesome as its an automatic vote, but all you see is a vote happened on a specific proposal number - you dont get any of the useful information.

There could be 2 possible ways to help end users of this information:

1. You greatly expand the event data emitted during the process, so at least we can account for all that happened
2. You add in an expiration, under the hood, on executed proposals, so at least that data gets saved to state and can be queryable at height

I prefer option (2) for obvious reasons, but would like something more than what is currently available.