Fixed Legit attachments sometimes marked as "unassociated" and disappear after 24 hours
- Thread starter webbouk
- Start date
Mr Lucky
Well-known member
I just had a different issue attaching PDF files, ie not to be shown as images within the posts just as attachments to the post for downloading.
I added them via the attach button, they should as attachments under the text editor but when posted they just weren't there.
I edited, attached again and this time there they were.
The first attempt showed as Unassociated:
I added them via the attach button, they should as attachments under the text editor but when posted they just weren't there.
I edited, attached again and this time there they were.
The first attempt showed as Unassociated:
JamesBrown
Well-known member
PaulB
Well-known member
That doesn't look right. That last parameter is supposed to be the temp hash, but it appears to contain JSON instead. That's probably going to exceed the 32-character
maxLength on Attachment's temp_hash field. When I forcefully set the hash to a long JSON string, I get the same stack trace as you.What's interesting is that errors don't seem to be bubbling.
ValueFormatter marks the error as please_enter_value_using_x_characters_or_fewer; however, Preparer's insertTemporaryAttachment simply discards the error and continues anyway. If save actually ran to completion, it might at least throw something useful, but the check on temp_hash being empty happens in Attachment's _preSave even when the entity is already known to have errors:
PHP:
protected function _preSave()
{
if (!$this->content_id)
{
if (!$this->temp_hash)
{
// $this->hasErrors() is true; this code shouldn't be running. The save will fail anyway.
//throw new \LogicException('Temp hash must be specified if no content is specified.');
}
$this->unassociated = true;
}
else
{
$this->temp_hash = '';
$this->unassociated = false;
}
}Commenting out the
throw statement does result in a proper error response, although it's not much more intuitive:
JSON:
{
"status": "error",
"errors": {
"temp_hash": "Please enter a value using 32 characters or fewer."
},
"errorHtml": {
"content": "\n\n<div class=\"blockMessage\">\n\t\n\t\tPlease enter a value using 32 characters or fewer.\n\t\n</div>",
"title": "Oops! We ran into some problems."
},
"visitor": {
"conversations_unread": "0",
"alerts_unviewed": "0",
"total_unread": "0"
},
"debug": {
"time": 0.0695,
"queries": 10,
"memory": 2.25
}
}However, this error is never displayed to the user, and the upload appears successful. One could argue that the error handling here is incorrect, but that wouldn't actually solve the issue. Somehow, you're ending with a bad
hash field.
Idhae
Active member
Look at that screenshot from DB, there are 4 entrys with that id stuff:
Post in thread 'Unassociated attachments' https://xenforo.com/community/threads/unassociated-attachments.190878/post-1501142
PaulB
Well-known member
Those should be MD5 hashes. I tried poking around to see if I could get JSON in there, but I can't find a way with a vanilla installation. That
hash value is passed as a querystring parameter even with POST requests; I'd be curious to see whether it shows up in your access logs, or whether it's getting overwritten server-side somehow.
JamesBrown
Well-known member
Me too. There are numerous threads, at least a couple of bug reports. What more can we do, apart from keep apologising to our customers.
Same here, 75% of our content is photos. Wish they would hurry up and figure this out for us all.
sbj
Well-known member
From the silence treatment it looks like they are working on this problem to figure out what happened wrong.
There are a lot of things one can criticize about XF but without a doubt in my 7 years the "bug treatment" worked excellent here on XenForo. You can always rely on them and they act fast when something happens like this, which almost never happens. So, I guess we'll get a patch release as soon as they fix it, let's be patient.
There are a lot of things one can criticize about XF but without a doubt in my 7 years the "bug treatment" worked excellent here on XenForo. You can always rely on them and they act fast when something happens like this, which almost never happens. So, I guess we'll get a patch release as soon as they fix it, let's be patient.
JamesBrown
Well-known member
sbj
Well-known member
Yeah, true. But I guess it is like the hen or egg problem. They are investigating the underlying issue and to confirm the issue they need to find the issue first. So I would say that is why we haven't heard from them much. The bug report was created, this thread and other ones do exist, they even replied in some of them as staff, so it is impossible for them not having seen this issue. We have to be patient.
Idhae
Active member
Yes, I think also.
But it would be nice to hearing something official from xenforo team.
We are trying to investigate this or give ideas, how to investigate this by ourselves.
There are many threads who discuss the same.
We all don't know why, but:
- some users in our forums are uploading attachments
- via drop-in
- via image insert button
- via attachment upload button
- this uploads are successful insert in the editor and written in the db as temporary attachment, a user wrote me also, that he can see that attachment successfull via preview
- but if the post is send, the rendered post, has only attachment-links with no permission error
- in the database you can see that this attachments has no content id and unassociated. i have posted screenshots (i think that the permission error happens that way)
- after cronjob that unassociated attachments deleted
- Then you can see that dead-links in posts
The screenshots I have posted are from a forum with custom add-ons.
But a user, who has this problem, was try to debugging that problem with me.
On another forum, which has no custom add-ons, he could report the same problem and i could see the same things happened, as i try to explain. Sorry for my bad english.
Edit: im really surprised about that error in log, that i have posted today, why this error don't throw earlier.
Last edited:
ProCom
Well-known member
We're still having this issue, even after disabling addons, and doing other troubleshooting 
Not sure if it helps, but today we had two members both report that when they had the issue happen, each time they go back into the post, edit it, re-upload the images, they work.
That's the same users, uploading the same images, using the same process, on the same platforms, in the same posts, but doing it a 2nd time (within the edit of the post) works.
(edited to add: a 3rd user just confirmed: "editing and saving the post seems to always fix the issue.")
Not sure if it helps, but today we had two members both report that when they had the issue happen, each time they go back into the post, edit it, re-upload the images, they work.
That's the same users, uploading the same images, using the same process, on the same platforms, in the same posts, but doing it a 2nd time (within the edit of the post) works.
(edited to add: a 3rd user just confirmed: "editing and saving the post seems to always fix the issue.")
At the moment there isn’t a clear picture of what is causing the issue or the steps required to reproduce the issue. The even more confusing thing is that there haven’t been any significant changes (if any) in the files responsible for attachment uploading between 2.2.0 and 2.2.3. Let alone from 2.2.2 and 2.2.3.
Even worse, we don’t appear to be experiencing the same issue here.
We’ll continue to monitor the replies to this and other threads about the issue and hope a pattern emerges between now and 2.2.4.
Merged a few threads into the existing bug report. We’ll update this thread with more details as the picture becomes clearer.
Even worse, we don’t appear to be experiencing the same issue here.
We’ll continue to monitor the replies to this and other threads about the issue and hope a pattern emerges between now and 2.2.4.
Merged a few threads into the existing bug report. We’ll update this thread with more details as the picture becomes clearer.
Last edited:
.
Just to be clear; is everyone seeing this specific error in their logs related to this issue?
And @Idhae is this happening every time? Could this error specifically arise if the user is uploading a particularly large file?
This may be the error you hit if the file size exceeds PHP's post_max_size value. So even if you are experiencing the unassociated attachment issue this error might not actually be indicative of it. This may be mostly a red herring.
Can you check your post_max_size value (you should be able to see it from the server environment report in your Admin CP) and see if it is higher or lower than your configured max upload file size in Options > Attachments?
sbj
Well-known member
I haven't had any ACP error logs so far, but my board is small compared to the other guys'. So maybe with enough attempts I would have gotten.
If it helps we can all share our server environment reports to see similarities? Or any other server side things for reporting? Happy to help.
Mr Lucky
Well-known member
But it has happened to me on this forum:
Cannot reproduce - Message is too long error when pasting image into editor
I got an error posting an attachment here: See here: https://xenforo.com/community/threads/link-checker-for-xenforo-2-x-by-addonslab-paid.143075/post-1499133 In that case the message seemed to post OK, but after it was posted, the image didn't show and the link is dead. Then I tried again in...
xenforo.com
And every time I have had the problem it is via drag and drop or (only once recently) the attach files button
Idhae
Active member
No, that error dosen't throw together, with my debugging test i described, i never saw that error before. I didn't test to reproduce this error with large files, we don't change any configs.
- PHP upload_max_filesize 128M
- Maximum attachment file size 10240KB
Our debugging user could reproduce the same error now: