Repository navigation
ROB: Do not crash when the AcroForm entry is not a dictionary - #4029
Conversation
stefan6419846
left a comment
stefan6419846
left a comment
There was a problem hiding this comment.
Please check the test failure (test_workflows.py::test_get_fields_warns).
|
Good catch, that was mine. The old cast let a null entry through to the existing None check, but calling get_object() on it raised AttributeError. A damaged file can leave the key present with no value, which I had not tested for. Fixed so a null entry is still treated as absent and only a wrong type is reported. I also added a test for the null case. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Fixed on the 28th - a damaged file can leave the key present with no value, and calling get_object() on it raised AttributeError. Null is treated as absent again, and there is a test for it now. |
f67856d to
debec8f
Compare
If a PDF has a /AcroForm entry that is not a dictionary, reading the form fields crashes. The code assumes the entry is a dictionary and looks for /Fields inside it. If it is a number, a string or an array instead, that check fails with a plain Python error.
get_fields already returns None when there is no /AcroForm at all, so now an entry it cannot read does the same thing and logs a warning.
This is the same problem as #4019, one level higher — that one fixed the /Fields array, this one fixes the /AcroForm entry itself.