Skip to content

Feature request: suspend actor on inactivity #424

Open

Description

@bowei

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.

Activity

  1. EItanya commented on Jul 12, 2026

    @EItanya
    Collaborator

    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

  2. levrado commented on Jul 13, 2026

    @levrado
    Contributor

    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

  3. ajaysundark commented on Sep 11, 2026

    @ajaysundark
    Contributor

    /cc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/apiUser-facing API changesarea/schedulingkind/featureAn enhancement / feature request or implementation

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions