Upgrade StorageISBN metadata retrieval leaves PDF unattached in Zotero 10
Debug ID: **D629664240** (Zotero 10.0.2).
Retrieving metadata for a standalone PDF creates the correct book record, but the PDF remains standalone. The book has no child attachment, and double-clicking it does nothing. The PDF file remains on disk.
I originally encountered this in Zotero 9.0.6 on Linux. After upgrading to Zotero 10.0.2, the issue persists; the Debug ID above is from the new reproduction.
Steps in the affected workflow:
1. Select My Library and add a PDF as a standalone attachment, without adding it to a collection.
2. Retrieve metadata for the PDF, automatically or through the context menu.
3. Wait for the book record to appear, then inspect its attachments and try opening it.
The affected PDF is *Classification of Higher Dimensional Algebraic Varieties* by Hacon and Kovács. In the original 9.0.6 trace, recognition uses ISBN `9783034602891` and the Library of Congress ISBN translator. In that run, I also opened the PDF while recognition was running; I have not isolated whether that affects the timing.
Expected: the original PDF becomes a child of the new book, and opening the book opens that PDF.
Actual: the new book and PDF remain separate. In the original 9.0.6 trace, attachment 912 still has `parentItemID=NULL` after book 913 is created.
The relevant sequence from the original 9.0.6 debug output, abridged, is:
```text
RecognizeDocument: Getting metadata by ISBN 9783034602891
RecognizeDocument: Recognized attachment 978-3-0346-0290-7
Beginning DB transaction irqZOVvo
Waiting for DB transaction irqZOVvo to finish to start pvrVMYct
Item 912 has not changed
Committed DB transaction irqZOVvo
Beginning DB transaction pvrVMYct
INSERT INTO items (...) VALUES (...) [913, ...]
...
UPDATE itemAttachments SET parentItemID=NULL, ... WHERE itemID=? [..., 912]
```
The source suggests a missing `await` in the ISBN branch of `_recognizePDF`. This branch requests metadata with `libraryID:false`, constructs a new `Zotero.Item`, and returns it immediately after starting `newItem.saveTx()`:
```js
newItem.saveTx();
return newItem;
```
[`_processItem`](https://github.com/zotero/zotero/blob/10.0.2/chrome/content/zotero/xpcom/recognizeDocument.js#L280-L293) then assigns `attachment.parentID = parentItem.id`. Without collection membership, its additional `await parentItem.save()` is skipped. If the initial save has not assigned an ID yet, the attachment receives an empty parent ID. The later book save does not repeat that assignment.
Proposed fix in the [ISBN branch](https://github.com/zotero/zotero/blob/10.0.2/chrome/content/zotero/xpcom/recognizeDocument.js#L484-L524):
```diff
-newItem.saveTx();
+await newItem.saveTx();
return newItem;
```
An isolated replay of the installed 9.0.6 `_recognizePDF` and `_processItem` function bodies, with stubbed services/database and a delayed item save, reproduces the missing link. Adding that `await` links the attachment correctly. The installed 10.0.2 recognition source contains the same unawaited ISBN save and attachment-linking code.
The same unawaited ISBN save is also present in the 10.0.3 and 10.0.4 source and current main as of 2026-09-28. Those later releases were checked by source inspection; the application failure has been observed in 9.0.6 and 10.0.2.
Suggested workaround: manually attach the existing standalone PDF to the book by dragging its library entry onto the book.
Retrieving metadata for a standalone PDF creates the correct book record, but the PDF remains standalone. The book has no child attachment, and double-clicking it does nothing. The PDF file remains on disk.
I originally encountered this in Zotero 9.0.6 on Linux. After upgrading to Zotero 10.0.2, the issue persists; the Debug ID above is from the new reproduction.
Steps in the affected workflow:
1. Select My Library and add a PDF as a standalone attachment, without adding it to a collection.
2. Retrieve metadata for the PDF, automatically or through the context menu.
3. Wait for the book record to appear, then inspect its attachments and try opening it.
The affected PDF is *Classification of Higher Dimensional Algebraic Varieties* by Hacon and Kovács. In the original 9.0.6 trace, recognition uses ISBN `9783034602891` and the Library of Congress ISBN translator. In that run, I also opened the PDF while recognition was running; I have not isolated whether that affects the timing.
Expected: the original PDF becomes a child of the new book, and opening the book opens that PDF.
Actual: the new book and PDF remain separate. In the original 9.0.6 trace, attachment 912 still has `parentItemID=NULL` after book 913 is created.
The relevant sequence from the original 9.0.6 debug output, abridged, is:
```text
RecognizeDocument: Getting metadata by ISBN 9783034602891
RecognizeDocument: Recognized attachment 978-3-0346-0290-7
Beginning DB transaction irqZOVvo
Waiting for DB transaction irqZOVvo to finish to start pvrVMYct
Item 912 has not changed
Committed DB transaction irqZOVvo
Beginning DB transaction pvrVMYct
INSERT INTO items (...) VALUES (...) [913, ...]
...
UPDATE itemAttachments SET parentItemID=NULL, ... WHERE itemID=? [..., 912]
```
The source suggests a missing `await` in the ISBN branch of `_recognizePDF`. This branch requests metadata with `libraryID:false`, constructs a new `Zotero.Item`, and returns it immediately after starting `newItem.saveTx()`:
```js
newItem.saveTx();
return newItem;
```
[`_processItem`](https://github.com/zotero/zotero/blob/10.0.2/chrome/content/zotero/xpcom/recognizeDocument.js#L280-L293) then assigns `attachment.parentID = parentItem.id`. Without collection membership, its additional `await parentItem.save()` is skipped. If the initial save has not assigned an ID yet, the attachment receives an empty parent ID. The later book save does not repeat that assignment.
Proposed fix in the [ISBN branch](https://github.com/zotero/zotero/blob/10.0.2/chrome/content/zotero/xpcom/recognizeDocument.js#L484-L524):
```diff
-newItem.saveTx();
+await newItem.saveTx();
return newItem;
```
An isolated replay of the installed 9.0.6 `_recognizePDF` and `_processItem` function bodies, with stubbed services/database and a delayed item save, reproduces the missing link. Adding that `await` links the attachment correctly. The installed 10.0.2 recognition source contains the same unawaited ISBN save and attachment-linking code.
The same unawaited ISBN save is also present in the 10.0.3 and 10.0.4 source and current main as of 2026-09-28. Those later releases were checked by source inspection; the application failure has been observed in 9.0.6 and 10.0.2.
Suggested workaround: manually attach the existing standalone PDF to the book by dragging its library entry onto the book.
-
dstillman Zotero Teamedited today at 1:48pmWe can fix the race here, but unless you can reproduce this in Troubleshooting Mode (Help → "Restart in Troubleshooting Mode…”), this is likely caused by one of your plugins.
-
AprilGrimoireHello! I restarted in Troubleshooting mode and the issue persists. D1662962841