Prior to the unified queue, the pending upcoming activities were all stored in their "final" tables - e.g. nano_commands, host_script_results, etc. but with some NULL column indicating that the actual result was pending. Some fleet behavior depended on that - e.g. summaries of host counts by state, deletion of pending script execution when a script is modified, etc.
We need to ensure those "pending state" behaviors are adjusted to work properly in the new unified queue world.
Most (possibly all?) of those places where the "pending" state depended on the upcoming activity to be in its final table were captured in the brainstorm document:
Prior to the unified queue, the pending upcoming activities were all stored in their "final" tables - e.g.
nano_commands,host_script_results, etc. but with some NULL column indicating that the actual result was pending. Some fleet behavior depended on that - e.g. summaries of host counts by state, deletion of pending script execution when a script is modified, etc.We need to ensure those "pending state" behaviors are adjusted to work properly in the new unified queue world.
Most (possibly all?) of those places where the "pending" state depended on the upcoming activity to be in its final table were captured in the brainstorm document: