# pet.trezy.getResetStatus

> Published by [trezy.pet](https://lexicon.garden/identity/did:plc:ollch4g7tes2reb5eceiwuol)

✓ This is the authoritative definition for this NSID.

## Links

- [View on Lexicon Garden](https://lexicon.garden/lexicon/did:plc:ollch4g7tes2reb5eceiwuol/pet.trezy.getResetStatus)
- [Documentation](https://lexicon.garden/lexicon/did:plc:ollch4g7tes2reb5eceiwuol/pet.trezy.getResetStatus/docs)
- [Examples](https://lexicon.garden/lexicon/did:plc:ollch4g7tes2reb5eceiwuol/pet.trezy.getResetStatus/examples)

## Definitions

### `pet.trezy.getResetStatus`

**Type**: `query`

The caller's most recent account reset, if they have ever started one. Answers the question the client asks on every load: is a reset running, did the last one finish, and did it finish cleanly.

A QUERY rather than a procedure because it is read-only and polled while a reset runs. It takes no parameters at all — it reports on `caller_did` and nothing else, so there is no way to watch somebody else's reset. Anonymous callers get a refusal rather than a 401: a Lua script cannot set its own HTTP status, and this is a status read rather than an action, so a 200 carrying `not-authenticated` is the honest shape.

#### Output

**Encoding**: `application/json`

| Property | Type | Required | Description |
|----------|------|----------|-------------|
| `error` | `string` | No | Present instead of a status. |
| `jobId` | `string` | No | The reset being reported on. |
| `status` | `string` | No | The job's state. `pending` and `running` both mean a reset is IN FLIGHT and the game should not be played over it — the ledger is being deleted underneath. `paused` and `cancelled` mean an operator stopped it, which leaves the documented partial state: the ledger is gone and some records may remain. |
| `failure` | `string` | No | The job's error, when it failed. Verbatim from the worker and not written for a player — show it as diagnostics to copy, not as the explanation. |
| `message` | `string` | No |  |
| `complete` | `boolean` | No | Whether the finished job cleared every ledger row. ⚠ ONLY MEANINGFUL WHEN `status` IS `completed`, and FALSE THERE MEANS THE ACCOUNT IS PARTIALLY RESET — the client must not send that player to onboarding, because a surviving row will refuse the first pet they pick. |
| `progress` | `ref` → `#progress` | No | The last snapshot the job wrote. Absent before it writes its first. |
| `survivingTables` | `array` | No | Ledger tables that could not be cleared. What to quote when reporting a failed reset. |

### `pet.trezy.getResetStatus#progress`

**Type**: `object`

The job's own snapshot, passed through as it was written. Every field is optional because the job writes different shapes at different phases, and a client that assumed otherwise would break the moment a phase was added.

| Property | Type | Required | Description |
|----------|------|----------|-------------|
| `phase` | `string` | No | Which part of the reset is happening. |
| `deleted` | `integer` | No | Records actually deleted. |
| `attempted` | `integer` | No | Records tried so far, whether or not they went. |
| `tablesDone` | `integer` | No |  |
| `clearedRows` | `integer` | No |  |
| `tablesTotal` | `integer` | No |  |
| `recordsTotal` | `integer` | No | Records found to delete. |

## Raw Schema

```json
{
  "id": "pet.trezy.getResetStatus",
  "defs": {
    "main": {
      "type": "query",
      "output": {
        "schema": {
          "type": "object",
          "required": [],
          "properties": {
            "error": {
              "type": "string",
              "description": "Present instead of a status.",
              "knownValues": [
                "not-authenticated",
                "unavailable"
              ]
            },
            "jobId": {
              "type": "string",
              "description": "The reset being reported on."
            },
            "status": {
              "type": "string",
              "description": "The job's state. `pending` and `running` both mean a reset is IN FLIGHT and the game should not be played over it — the ledger is being deleted underneath. `paused` and `cancelled` mean an operator stopped it, which leaves the documented partial state: the ledger is gone and some records may remain.",
              "knownValues": [
                "pending",
                "running",
                "completed",
                "failed",
                "paused",
                "cancelled"
              ]
            },
            "failure": {
              "type": "string",
              "description": "The job's error, when it failed. Verbatim from the worker and not written for a player — show it as diagnostics to copy, not as the explanation."
            },
            "message": {
              "type": "string"
            },
            "complete": {
              "type": "boolean",
              "description": "Whether the finished job cleared every ledger row. ⚠ ONLY MEANINGFUL WHEN `status` IS `completed`, and FALSE THERE MEANS THE ACCOUNT IS PARTIALLY RESET — the client must not send that player to onboarding, because a surviving row will refuse the first pet they pick."
            },
            "progress": {
              "ref": "#progress",
              "type": "ref",
              "description": "The last snapshot the job wrote. Absent before it writes its first."
            },
            "survivingTables": {
              "type": "array",
              "items": {
                "type": "string"
              },
              "description": "Ledger tables that could not be cleared. What to quote when reporting a failed reset."
            }
          }
        },
        "encoding": "application/json"
      },
      "description": "The caller's most recent account reset, if they have ever started one. Answers the question the client asks on every load: is a reset running, did the last one finish, and did it finish cleanly.\n\nA QUERY rather than a procedure because it is read-only and polled while a reset runs. It takes no parameters at all — it reports on `caller_did` and nothing else, so there is no way to watch somebody else's reset. Anonymous callers get a refusal rather than a 401: a Lua script cannot set its own HTTP status, and this is a status read rather than an action, so a 200 carrying `not-authenticated` is the honest shape."
    },
    "progress": {
      "type": "object",
      "required": [],
      "properties": {
        "phase": {
          "type": "string",
          "description": "Which part of the reset is happening.",
          "knownValues": [
            "starting",
            "listed",
            "ledger",
            "records",
            "done"
          ]
        },
        "deleted": {
          "type": "integer",
          "description": "Records actually deleted."
        },
        "attempted": {
          "type": "integer",
          "description": "Records tried so far, whether or not they went."
        },
        "tablesDone": {
          "type": "integer"
        },
        "clearedRows": {
          "type": "integer"
        },
        "tablesTotal": {
          "type": "integer"
        },
        "recordsTotal": {
          "type": "integer",
          "description": "Records found to delete."
        }
      },
      "description": "The job's own snapshot, passed through as it was written. Every field is optional because the job writes different shapes at different phases, and a client that assumed otherwise would break the moment a phase was added."
    }
  },
  "$type": "com.atproto.lexicon.schema",
  "lexicon": 1
}
```