You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ATE currently requires an explicit API call to suspend Actors, which works well for use cases where there is an external controller that knows clear resume and suspend lifetime cycle. This works less well for long-living but mostly idle Actors where we will want to be able to integrate automatic suspension via externally observable signals, such as request traffic or system activity (CPU).
There are a couple of layers/choice to this:
Does this functionality have to be built vertically into Substrate in a deep integration or we expose the right surface area to allow someone to implement this easily? Specifically, does Substrate offer just an API for idle suspend or enables enough visibility/triggers into Actor behavior that it is easy to build and integrate with.
An idle suspend API should be built that is generic to the idle signal: IMO it would be bad to have separate "idle suspend due to network", "idle suspend due to CPU" etc that are not coordinate with each other.
In terms of direct integration vs pluggable I'm a bit torn. Traditional signals may lag a bit too much for this sort of feature. Imagine a traditional telemetry gathering system with acceptable seconds of lag. Seconds of lag could lead to incorrect signals here. I think for this feature to be successful it needs to be able to respond quickly and accurately to "inactive" actors. This also has much less downside than a traditional inactivity mechanism because pause/resume should be much much faster.
I don't have an answer for this yet, just putting some thoughts down
IMO It calls for something HPA-like, pluggable policy API that can combine signals such as traffic, in-flight work, CPU usage, and harness state. ateom could eventually provide runtime-local metrics as one of those signal sources.
simpler than hpa since only 2 states of active/suspend ofc
in regards of speed if its in ATE itself, should be able to respond very quickly if api is strict enough
Activity
EItanya commentedon Jul 12, 2026
100% on this feature.
In terms of direct integration vs pluggable I'm a bit torn. Traditional signals may lag a bit too much for this sort of feature. Imagine a traditional telemetry gathering system with acceptable seconds of lag. Seconds of lag could lead to incorrect signals here. I think for this feature to be successful it needs to be able to respond quickly and accurately to "inactive" actors. This also has much less downside than a traditional inactivity mechanism because pause/resume should be much much faster.
I don't have an answer for this yet, just putting some thoughts down
levrado commentedon Jul 13, 2026
IMO It calls for something HPA-like, pluggable policy API that can combine signals such as traffic, in-flight work, CPU usage, and harness state. ateom could eventually provide runtime-local metrics as one of those signal sources.
simpler than hpa since only 2 states of active/suspend ofc
in regards of speed if its in ATE itself, should be able to respond very quickly if api is strict enough
ajaysundark commentedon Sep 11, 2026
/cc