XF 2.2 R2 & File not found errors

[eDaddi]

Since switching to Cloudflare's R2 buckets I'm getting hundreds of these 'File not found at path: attachments' error messages.

Server error log

• League\Flysystem\FileNotFoundException: File not found at path: attachments/388/388451-be3fcf044e00c8226086ca12ec7db791.data
• src/addons/DigitalPoint/Cloudflare/League/Flysystem/Adapter/R2.php:132
• Generated by: {redacted}
• Mar 18, 2024 at 9:01 PM

Stack trace​

#0 src/addons/DigitalPoint/Cloudflare/League/Flysystem/Adapter/R2.php(108): DigitalPoint\Cloudflare\League\Flysystem\Adapter\R2->read('attachments/388...')
#1 src/vendor/league/flysystem/src/Filesystem.php(196): DigitalPoint\Cloudflare\League\Flysystem\Adapter\R2->readStream('attachments/388...')
#2 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(430): League\Flysystem\Filesystem->readStream('attachments/388...', Array)
#3 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(395): League\Flysystem\EventableFilesystem\EventableFilesystem->callFilesystemMethod('readStream', Array)
#4 src/vendor/league/flysystem-eventable-filesystem/src/EventableFilesystem.php(154): League\Flysystem\EventableFilesystem\EventableFilesystem->delegateMethodCall('readStream', Array)
#5 src/vendor/league/flysystem/src/MountManager.php(345): League\Flysystem\EventableFilesystem\EventableFilesystem->readStream('attachments/388...')
#6 src/XF/Pub/View/Attachment/View.php(25): League\Flysystem\MountManager->readStream('attachments/388...')
#7 src/XF/Mvc/Renderer/AbstractRenderer.php(91): XF\Pub\View\Attachment\View->renderRaw()
#8 src/XF/Mvc/Renderer/Raw.php(39): XF\Mvc\Renderer\AbstractRenderer->renderViewObject('XF:Attachment\\V...', '', Array)
#9 src/XF/Mvc/Dispatcher.php(460): XF\Mvc\Renderer\Raw->renderView('XF:Attachment\\V...', '', Array)
#10 src/XF/Mvc/Dispatcher.php(442): XF\Mvc\Dispatcher->renderView(Object(XF\Mvc\Renderer\Raw), Object(XF\Mvc\Reply\View))
#11 src/XF/Mvc/Dispatcher.php(402): XF\Mvc\Dispatcher->renderReply(Object(XF\Mvc\Renderer\Raw), Object(XF\Mvc\Reply\View))
#12 src/XF/Mvc/Dispatcher.php(60): XF\Mvc\Dispatcher->render(Object(XF\Mvc\Reply\View), 'raw')
#13 src/XF/App.php(2487): XF\Mvc\Dispatcher->run()
#14 src/XF.php(524): XF\App->run()
#15 index.php(19): XF::runApp('XF\\Pub\\App')
#16 {main}

Request state​

array(4) {
["url"] => string(44) "/attachments/img_20210701_015046-jpg.797178/"
["referrer"] => string(53) "https://{redacted}.com/threads/{redacted}.399816/"
["_GET"] => array(0) {
}
["_POST"] => array(0) {
}
}

Using:

SELECT * FROM xf_attachment WHERE data_id = 388451;
SELECT * FROM xf_attachment_data WHERE data_id = 388451;
SELECT * FROM xf_attachment_data WHERE file_hash = 'be3fcf044e00c8226086ca12ec7db791';

Resulted in:


So that data ID (388451) is found in a post and an XFMG album. It exists in the DB.

If I take the

attachments/388/388451-be3fcf044e00c8226086ca12ec7db791.data

portion of the error and change the '.data' to '.jpg' in the browser I get a 404 error as expected.

When I add the Cloudflare-managed subdomain 'data' to the same URL the image pulls up fine. This is the case for all of these type errors.

Any thoughts on what would causing some attachments to error out like this and not others?

 

[digitalpoint]

FWIW, my Cloudflare/R2 addon intentionally doesn’t suppress attachment data missing error. By default XenForo hides that there’s an issue and doesn’t let the admin know (only the end user sees an error). So if you have old attachments that have been missing data for a long time, you might only now know they have missing data (the actual attachment).

If you don’t have the ability to restore the missing data from a (probably very old) backup, you may want to consider deleting the attachment(s) causing the error. An attachment record without the attachment itself (its data) is more or less pointless since the underlying attachment doesn’t exist. And for whatever reason XenForo by default suppresses any error about missing attachment data.

 

[eDaddi]

FWIW, my Cloudflare/R2 addon intentionally doesn’t suppress attachment data missing error. By default XenForo hides that there’s an issue and doesn’t let the admin know (only the end user sees an error). So if you have old attachments that have been missing data for a long time, you might only now know they have missing data (the actual attachment).

I hear ya. Many of these are not old though, it happens with newer ones as well. The one shared above has an attach date from 'Wednesday, January 10, 2024 1:12:11 AM'. I have not made any major changes since then so I'm stumped at what causes that.

If you don’t have the ability to restore the missing data from a (probably very old) backup, you may want to consider deleting the attachment(s) causing the error. An attachment record without the attachment itself (its data) is more or less pointless since the underlying attachment doesn’t exist. And for whatever reason XenForo by default suppresses any error about missing attachment data.

The attachment is in the R2 bucket, along with several others from that user's same post. This one, for whatever reason, does not get the subdomain added to the URL and shows up as a missing attachment.

 

[digitalpoint]

How did you migrate existing data to R2? I’d triple check that it exists in R2 and more specifically that it has more than 0 bytes and that the full object key is correct (key = “path” in a traditional filesystem). Like make sure the prefix is right… (not leading slash or anything).

 

[eDaddi]

How did you migrate existing data to R2?

I think I downloaded and uploaded to R2? Maybe a direct connection it's been awhile so I don't recall. Either way this user added this pic months (years?) after that was done.

How did you migrate existing data to R2? I’d triple check that it exists in R2 and more specifically that it has more than 0 bytes and that the full object key is correct (key = “path” in a traditional filesystem). Like make sure the prefix is right… (not leading slash or anything).

It's got size and aside from the image file name itself this CF info looks exactly like the images the user posted above and below this one that doesn't work

 

[digitalpoint]

You are looking in the wrong bucket. You are looking in the data (public) bucket and the error is from your internal data filesystem. Also the “path” doesn’t match either (different extensions there).

 

[eDaddi]

You are looking in the wrong bucket

Derp ....


Just noticed the hash doesn't match

 

[digitalpoint]

So the error is legit… the file doesn’t exist. But the question is why the hash changed. On the R2 side of things you can’t rename or edit a file, only upload a new one. So the hash on the R2 side has been that since the file was created in January. Have you run any addons lately that might be altering attachments? The hash is generated from the attachment content. So if something is changing the content of an attachment somehow, the hash is going to change along with it.

 

[Claudio]

Have you run any addons lately that might be altering attachments?

The Image Optimizer addon of @truonglv is causing issues with missing attachments, maybe it's related:

Post in thread 'Image Optimizer for XF 2.0 [Paid]'

Jan 18, 2024

Is anyone seeing an increase in issues where this addon is deleting attachments as they are processed? I've been helping with a site that had this installed, and when the image was being optimized, it was logged that it was being optimized, and then the .data file was removed from the file system, resulting in missing attachments.

• MattW

• 

 

[eDaddi]

The Image Optimizer addon of @truonglv is causing issues with missing attachments, maybe it's related:

Post in thread 'Image Optimizer for XF 2.0 [Paid]'

Jan 18, 2024

Is anyone seeing an increase in issues where this addon is deleting attachments as they are processed? I've been helping with a site that had this installed, and when the image was being optimized, it was logged that it was being optimized, and then the .data file was removed from the file system, resulting in missing attachments.

• MattW

• 

I am running that as well.

The logs show it touched this attachment about 10min after the user posted it:

 

[Claudio]

I am running that as well.

Then I recommend you to reach @truonglv who hasn't been responsible regarding this issue.

 

[eDaddi]

Then I recommend you to reach @truonglv who hasn't been responsible regarding this issue.

Will do that now.

Of the 929 files XF has logged with this error, 709 of them appear in the add-on's log and 157 of them have a new size of 0.

 

[eDaddi]

After looking at this more this AM ...

I got to thinking I could just:

1. Run a query on the error log looking for these missing images.
2. Use the data_id in the error string to locate that data_id's record in the xf_attachment_data table.
3. If the hash from the error log doesn't match the data_id's hash in the xf_attachment_data, replace the DB's hash with the error's hash to fix the image.
   1. I did this manually for a few and it worked like a charm. Images that displayed the red x on the front end and 500 error codes in the console were now fixed.

However .... Of the 121 DB records that have a diffrent hash in the error message vs whats in the DB ... the vast majority of those attachments display just fine on the front end. I thought that none of them would display an image if there is a different hash, but I very few were truly a broke/missing image.

So now I'm wondering if:

1. The error logs are being incorrectly generated which is why the hash in the error log doesn't match the attachments hash in the DB -or-
2. The code generating the front end has a bug that, for whatever reason, doesn't use the attachment's hash thats in the DB which creates this error.

Am I completely thinking about the wrong?

 

[digitalpoint]

Replacing the hash (and other pertinent info) would probably work ok. But it still doesn’t solve the underlying issue of why it was changed to begin with (I’d focus on solving that first so you aren’t just manually fixing the same attachments over and over going forward).

 

[eDaddi]

But it still doesn’t solve the underlying issue of why it was changed to begin with

I hear ya, this part is still getting me:

Of the 121 DB records that have a diffrent hash in the error message vs whats in the DB ... the vast majority of those attachments display just fine on the front end. I thought that none of them would display an image if there is a different hash, but I very few were truly a broke/missing image.

Why is the hash wrong in the error msg?

 

[digitalpoint]

I hear ya, this part is still getting me:

Why is the hash wrong in the error msg?

The hash doesn’t get altered in XenForo, so it’s coming from one of the attachment tables.

 

[MattW]

Why is the hash wrong in the error msg?

The image optimiser addon changes the hash when it does what it does. That addon is now causing more issues than it solves, so either downgrade to 2.1.7 or get rid, as the author is ignoring all the issues we are reporting with it.