---
apiVersion: data-spec/v1
id: delete-folder-orphan-metadata-20260409
description: "Remove orphan _System_Object row for 'folder' (no physical table exists)"
created: 2026-04-09
applied: 2026-04-09
scope: production-only
status: applied
applied_to:
  - tidb-branch xiaopeng-dev-test (bran-v3dchq6be5fe3nlpwo7mv6akem)
tables: [_System_Object, _System_Field]
depends_on: []
---

# Delete `folder` Orphan Metadata

## Summary

The `_System_Object` registry on the TiDB Cloud branch
`bran-v3dchq6be5fe3nlpwo7mv6akem` contained an entry with `ApiName='folder'`
(Id `5d14c5a3-9e72-4bc3-87b2-5c2481943931`, TableType `system_metadata`, 15
fields registered in `_System_Field`). However, **no physical table named
`folder` exists** in the database — this is pure orphan metadata, likely a
leftover from an earlier import/migration that was never cleaned up.

The orphan was discovered during bootstrap startup assertion investigation
(issue referenced in ywang-official/MetaDrivenPlatform4AI#474). It triggered a
`SchemaMismatch` assertion violation:

> Metadata exists for object 'folder', but the database table is missing.

Because no physical table exists, no user data is at risk. The only
consumers of this metadata row are the bootstrap assertions and, potentially,
cached metadata queries that reference `ApiName='folder'` (there are none in
the current codebase — verified by grep on 2026-04-09).

Local TiDB (`127.0.0.1:4000/nexuscrm`) was checked and has no such row — this
cleanup only applies to the TiDB branch.

## Changes

### 1. Delete _System_Field rows linked to the 'folder' object

```sql
DELETE f FROM _System_Field f
JOIN _System_Object o ON f.ObjectId = o.Id
WHERE o.ApiName = 'folder';
```

**Idempotency**: The JOIN returns zero rows once the parent `_System_Object`
row is gone. Re-running after the cleanup is a no-op.

### 2. Delete the 'folder' _System_Object row

```sql
DELETE FROM _System_Object
WHERE ApiName = 'folder';
```

**Idempotency**: `WHERE ApiName='folder'` targets at most one row. If already
deleted, `ROW_COUNT()` returns 0 and the statement is a no-op.

**Safety**:
- No physical table named `folder` exists (verified via
  `information_schema.tables` at apply time)
- No references found in: `_System_Layout`, `_System_Action`, or any
  application code (verified via grep on 2026-04-09)
- Deleting only the registry metadata row cannot cause data loss because
  there is no table behind it

## Rollback

Rolling back is **not possible** without a backup snapshot of the original
row. The deleted row had these known identifying properties:

- `Id` = `5d14c5a3-9e72-4bc3-87b2-5c2481943931`
- `ApiName` = `folder`
- `TableType` = `system_metadata`
- 15 associated `_System_Field` rows (exact values not snapshotted)

If recovery is required, restore from a pre-2026-04-09 backup of the
TiDB Cloud branch. The row cannot be recreated deterministically from this
spec alone because the field definitions were not captured.

**Mitigation**: If `folder` needs to exist as a real managed object in the
future, add it to `backend/internal/bootstrap/system_tables.json` and let the
normal bootstrap path create both the physical table and the metadata.

## Verification

After apply, confirm the row is gone:

```sql
SELECT COUNT(*) AS should_be_zero FROM _System_Object WHERE ApiName = 'folder';
-- Expected: 0

SELECT COUNT(*) AS should_be_zero FROM _System_Field f
WHERE NOT EXISTS (SELECT 1 FROM _System_Object o WHERE o.Id = f.ObjectId)
  AND f.ObjectId = '5d14c5a3-9e72-4bc3-87b2-5c2481943931';
-- Expected: 0
```

Confirmed on 2026-04-09 after apply — both queries returned 0.