Update the signatures-helpers to actually handle MissingDataExceptions - #21652
Conversation
The `PDFDocument.prototype.signatures` getter returns a (shadowed) Promise, however the way that it invokes various helper-methods can lead to *intermittent* failures to parse the signature data. These helper-methods will lookup a fair amount of Dictionary data, however any one of those cases could throw `MissingDataException` during document loading. To avoid having to re-factor those methods a lot, and adding a bunch more `pdfManager.ensureDoc()` calls, they are instead made asynchronous and the Dictionary lookups changed to use `Dict.prototype.getAsync` (similar to the existing `fieldObjects` handling). Technically this additional asynchronicity may be ever so slightly slower, however I don't think it matters in practice since: most PDFs don't have any signatures, the signature-UI is initialized lazily in the viewer, and finally fetching/parsing of signatures do not block rendering. Also, note how multiple values are being fetched in parallel in order to attempt to reduce overall asynchronicity. *Note:* The unit-test changes are essentially fixing pre-existing bugs, that this patch exposed, since the test-only `Dict` instances weren't able to fetch indirect objects.
Given that these checks are synchronous, we can avoid a little bit of unnecessary data-fetching if the `ByteRange` is invalid.
…atureDict` method
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #21652 +/- ##
==========================================
- Coverage 89.83% 89.83% -0.01%
==========================================
Files 263 263
Lines 66899 66888 -11
==========================================
- Hits 60100 60086 -14
- Misses 6799 6802 +3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
timvandermeij
left a comment
There was a problem hiding this comment.
r=me, with passing browser tests. Thank you for improving this!
|
/botio browsertest |
From: Bot.io (Linux m4)ReceivedCommand cmd_browsertest from @timvandermeij received. Current queue size: 0 Live output at: http://54.241.84.105:8877/7e55c3e407e5661/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_browsertest from @timvandermeij received. Current queue size: 1 Live output at: http://54.193.163.58:8877/26d25e84d922709/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/7e55c3e407e5661/output.txt Total script time: 17.96 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.193.163.58:8877/26d25e84d922709/output.txt Total script time: 23.40 mins
|
The
PDFDocument.prototype.signaturesgetter returns a (shadowed) Promise, however the way that it invokes various helper-methods can lead to intermittent failures to parse the signature data.These helper-methods will lookup a fair amount of Dictionary data, however any one of those cases could throw
MissingDataExceptionduring document loading.To avoid having to re-factor those methods a lot, and adding a bunch more
pdfManager.ensureDoc()calls, they are instead made asynchronous and the Dictionary lookups changed to useDict.prototype.getAsync(similar to the existingfieldObjectshandling).Technically this additional asynchronicity may be ever so slightly slower, however I don't think it matters in practice since: most PDFs don't have any signatures, the signature-UI is initialized lazily in the viewer, and finally fetching/parsing of signatures do not block rendering.
Also, note how multiple values are being fetched in parallel in order to attempt to reduce overall asynchronicity.
Note: The unit-test changes are essentially fixing pre-existing bugs, that this patch exposed, since the test-only
Dictinstances weren't able to fetch indirect objects.