# pet.trezy.resetAccount

> 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.resetAccount)
- [Documentation](https://lexicon.garden/lexicon/did:plc:ollch4g7tes2reb5eceiwuol/pet.trezy.resetAccount/docs)
- [Examples](https://lexicon.garden/lexicon/did:plc:ollch4g7tes2reb5eceiwuol/pet.trezy.resetAccount/examples)

## Definitions

### `pet.trezy.resetAccount`

**Type**: `procedure`

Queue the erasure of everything the game knows about the caller. THE MOST DESTRUCTIVE CALL IN THE GAME AND IT CANNOT BE UNDONE — pets, money, the starter grant, the high-water mark and every record in the caller's repo.

It ENQUEUES rather than doing the work, and returns a job id to watch with pet.trezy.getResetStatus. That is not for the progress bar's sake: the erasure makes one PDS round trip PER RECORD, activity records accrue one per interaction, and XRPC scripts have an instruction limit and a request timeout that job scripts explicitly do not. Done synchronously it would work on a barely-used account and time out half way through a played one, which is the single thing this call must never do.

The two halves keep their different guarantees inside the job: the SERVER LEDGER must go, and the job reports `complete: false` if any of it survived. The caller's REPO is only attempted — a record left behind is inert, because nothing in the ledger vouches for it and the guards treat it as one the game did not write.

#### Input

**Encoding**: `application/json`

| Property | Type | Required | Description |
|----------|------|----------|-------------|
| `confirm` | `string` | Yes | Must be exactly `reset my account`. A second pair of hands on a call that destroys everything: the client asks the player to confirm, and this makes a stray or mis-wired call — an empty body, a retry of the wrong request — refuse rather than wipe somebody. It is not security; the caller could always send it. It is a guard against accident. |

#### Output

**Encoding**: `application/json`

| Property | Type | Required | Description |
|----------|------|----------|-------------|
| `error` | `string` | No | Present instead of a job. A stable machine code. |
| `jobId` | `string` | No | The queued job. Watch it with pet.trezy.getResetStatus. |
| `message` | `string` | No |  |
| `alreadyRunning` | `boolean` | No | True when a reset was ALREADY in flight and `jobId` names that one rather than a new one. Not an error: a double-press or a reload of the confirmation should land the player on the progress they already started, not on a complaint about it. |

## Raw Schema

```json
{
  "id": "pet.trezy.resetAccount",
  "defs": {
    "main": {
      "type": "procedure",
      "input": {
        "schema": {
          "type": "object",
          "required": [
            "confirm"
          ],
          "properties": {
            "confirm": {
              "type": "string",
              "description": "Must be exactly `reset my account`. A second pair of hands on a call that destroys everything: the client asks the player to confirm, and this makes a stray or mis-wired call — an empty body, a retry of the wrong request — refuse rather than wipe somebody. It is not security; the caller could always send it. It is a guard against accident.",
              "knownValues": [
                "reset my account"
              ]
            }
          }
        },
        "encoding": "application/json"
      },
      "output": {
        "schema": {
          "type": "object",
          "required": [],
          "properties": {
            "error": {
              "type": "string",
              "description": "Present instead of a job. A stable machine code.",
              "knownValues": [
                "not-confirmed",
                "not-queued"
              ]
            },
            "jobId": {
              "type": "string",
              "description": "The queued job. Watch it with pet.trezy.getResetStatus."
            },
            "message": {
              "type": "string"
            },
            "alreadyRunning": {
              "type": "boolean",
              "description": "True when a reset was ALREADY in flight and `jobId` names that one rather than a new one. Not an error: a double-press or a reload of the confirmation should land the player on the progress they already started, not on a complaint about it."
            }
          }
        },
        "encoding": "application/json"
      },
      "description": "Queue the erasure of everything the game knows about the caller. THE MOST DESTRUCTIVE CALL IN THE GAME AND IT CANNOT BE UNDONE — pets, money, the starter grant, the high-water mark and every record in the caller's repo.\n\nIt ENQUEUES rather than doing the work, and returns a job id to watch with pet.trezy.getResetStatus. That is not for the progress bar's sake: the erasure makes one PDS round trip PER RECORD, activity records accrue one per interaction, and XRPC scripts have an instruction limit and a request timeout that job scripts explicitly do not. Done synchronously it would work on a barely-used account and time out half way through a played one, which is the single thing this call must never do.\n\nThe two halves keep their different guarantees inside the job: the SERVER LEDGER must go, and the job reports `complete: false` if any of it survived. The caller's REPO is only attempted — a record left behind is inert, because nothing in the ledger vouches for it and the guards treat it as one the game did not write."
    }
  },
  "$type": "com.atproto.lexicon.schema",
  "lexicon": 1
}
```