Cache dict is overriden after write_pdf (breaking it)

[jbtwist]

I'm using WeasyPrint 61.2 in my web app to send email in bulk to many users. These emails might have attached PDF's that I generate using the library. For performance, I use the cache kwarg to avoid generating multiple times my pictures.

When I start sending emails in bulk, in the first iteration, weasyprint generates the PNG file and stores it in my cache after calling Document.build_formatting_structure. This method generates this cache:

Where every picture has 2 entries, one with a hash identifying it, and another with the image url.

This continues executing html.write_pdf method normally, but after finishing, my cache has changed to this:

The problem comes with next iterations of html.write_pdf.
My cache has changed and the method Document.build_formatting_structure is not returning it to it's previous state.

When the code continues and arrives the moment of getting the data from my PNG in RasterImage.get_x_object, self.image.data does not contain the PNG Bytes we see in the first picture but the Bytes we see in the second one, causing it to fail raising UnidentifiedImageError('cannot identify image file <_io.BytesIO object at 0x11db6c5e0>')

I have tried with all my heart to solve this by myself as you might see, but I don't find the place where the cache is changing, nor understanding what is it writing on it's place.

[liZe]

There’s definitely a problem, thanks for reporting.

[alexandergitter]

While I can't say I completely understand the code, it appears to be related to how RasterImage uses the same cache key for different data (at least in the case of png):

• it first stores the entire file at the end of __init__ (https://github.com/Kozea/WeasyPrint/blob/main/weasyprint/images.py#L93)
• which then later gets read by get_x_object and overridden at the end of the same method (https://github.com/Kozea/WeasyPrint/blob/main/weasyprint/images.py#L205)

The data written by get_x_object is not the entire png file though - it gets mangled by _get_png_data, which e.g. removes the png header.
Another run with the same cache then fails because get_x_object itself expects to read a full png file in different places.

This also appears to be closely related to #1942, which afaict fails for the same underlying reason.

[liZe]

While I can't say I completely understand the code, it appears to be related to how RasterImage uses the same cache key for different data (at least in the case of png):

Yes, you’re right. I’ll fix the bug as soon as I can.

[jbtwist]

Many thanks for the quick action and finding the proper bug. I tried my best to do it but I felt uncapable (or at least I would take a lot of time and I had more work to do) due to my lack of awareness of the whole project, I gave all the info I was able to discover by myself.

[liZe]

Thanks a lot for the report and the investigation. Feedback is welcome!