Feature Category
Problem Statement
When debugging sandbox lifecycle issues (e.g. a sandbox that was restarted multiple times, or stopped unexpectedly), there is no way to see the history of state transitions. Operators and SDK users must rely on scattered log entries across distributed nodes to piece together what happened and when, which is time-consuming and error-prone.
Proposed Solution
Record every state machine transition (from_state, to_state, event, timestamp) and expose the history through the existing get_status API — no new endpoints needed.
Detailed Feature Description
- Each state transition (e.g. pending→running, running→stopped, stopped→pending on restart) is automatically recorded with a timestamp.
- The transition history is stored as part of the sandbox metadata and persisted through the existing meta_store.
- The history is returned in the
state_history field of the get_status response, making it available to both old and new SDK versions (old SDKs silently ignore the new field).
- History is capped at 100 entries to prevent unbounded growth in long-lived sandboxes.
- Self-transitions (e.g. stopped→stopped) are excluded to keep the history meaningful.
Feature Category
Problem Statement
When debugging sandbox lifecycle issues (e.g. a sandbox that was restarted multiple times, or stopped unexpectedly), there is no way to see the history of state transitions. Operators and SDK users must rely on scattered log entries across distributed nodes to piece together what happened and when, which is time-consuming and error-prone.
Proposed Solution
Record every state machine transition (from_state, to_state, event, timestamp) and expose the history through the existing
get_statusAPI — no new endpoints needed.Detailed Feature Description
state_historyfield of theget_statusresponse, making it available to both old and new SDK versions (old SDKs silently ignore the new field).