Why Missing?

[Zack-Rider]

Bug Report: Document Count Discrepancy (486 vs 484)

Summary

Customer's documents table has 486 rows but the knowledge base (Coyax) shows only 484 documents as Added_To_DB. The 2 extra rows are orphaned — their source parser jobs were deleted from Coyax but the customer DB was never cleaned up.

---

The 2 Missing/Orphaned Documents

These document_parser_job_id values exist in the customer's documents table but their DocumentParserJob records no longer exist in Coyax:

#	document_parser_job_id
1	007d8559-de28-4a5e-8dc0-a8bf940f8c89
2	45f43e2f-ef9e-4b31-8728-17fa100e6c66

To see the full document details, run in customer's NeonDB:

SELECT id, document_number, document_type, date, customer_id, document_parser_job_id
FROM documents
WHERE document_parser_job_id IN (
  '007d8559-de28-4a5e-8dc0-a8bf940f8c89',
  '45f43e2f-ef9e-4b31-8728-17fa100e6c66'
);

---

Root Cause

When a document is deleted from the storage page, two code paths exist:

Path 1 — Delete single job (deleteDocumentParserJob in server/src/routers/general.ts:9):

await prisma.documentParserJob.delete({ where: { id: input.id } });
await prisma.fileMetadata.delete({ where: { id: job.fileMetadataId } });

Path 2 — Bulk delete files (deleteFiles in server/src/routers/general.ts:64):

await tx.fileMetadata.deleteMany({ where: { id: { in: input.ids } } });

Neither path deletes the corresponding row from the customer's documents table.

The customer DB is a separate NeonDB instance (Org.databaseUrl). It is not connected via Prisma cascade — it requires an explicit delete using the document_parser_job_id foreign key.

---

Impact

Location	Count
Customer documents table	486
Coyax Added_To_DB parser jobs	484
Orphaned rows	2

The 2 orphaned documents reference deleted parser jobs. Their source files no longer exist in S3 or the knowledge base, but the extracted data rows remain in the customer's DB indefinitely.

---

Fix Required

In server/src/routers/general.ts, after deleting a parser job, also delete the corresponding row from the customer's documents table using the org's databaseUrl.

Both deleteDocumentParserJob and deleteFiles mutations need this cleanup step.

---

Immediate Remediation (Manual)

To clean up the 2 orphaned rows, run in customer's NeonDB:

-- Verify first (safe read)
SELECT id, document_number, document_type, date
FROM documents
WHERE document_parser_job_id IN (
  '007d8559-de28-4a5e-8dc0-a8bf940f8c89',
  '45f43e2f-ef9e-4b31-8728-17fa100e6c66'
);

-- Then delete (confirm the SELECT looks correct first)
DELETE FROM documents
WHERE document_parser_job_id IN (
  '007d8559-de28-4a5e-8dc0-a8bf940f8c89',
  '45f43e2f-ef9e-4b31-8728-17fa100e6c66'
);

After this, the count will be 484 matching the knowledge base.