https://bugzilla.wikimedia.org/show_bug.cgi?id=32551
Bawolff (Brian Wolff) <bawolff...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Descriptionless files |Descriptionless files
| |(Missing page_latest
| |referential integrity
| |issue)
--- Comment #34 from Bawolff (Brian Wolff) <bawolff...@gmail.com> ---
I was finally able to reproduce this.
Steps to reproduce:
*Make sure $wgEnableAsyncUploads = true;
*Artificially make it so that Revision::insertOn throws some sort of exception.
My current theory is that maybe very intermitent issue with external store dbs
is triggering the "Unable to store text to external storage" exception in
ExternalStore::insertWithFallback. That's just a random guess based on the
proximity of one approximately the db inserts fail. Could be totally wrong.
Anyway, its probably somewhere around that block of code. Someone with access
to job queue log could confirm if there are any common exceptions in the log,
and look at the results of the upload job for the various example files in
question.
*Upload an image using the api and stashed upload, making sure that the async
option is specified.
*Do runJobs.php --type PublishStashedFile to publish the file. This should
return an error from the exception triggered via step 2
Actual behaviour:
*Locally (I don't know about commons), the upload api does correctly report a
stash failure error to the user. Which is as it should be
*Image does not show up until page is action=purge or ~24hours, as the negative
entry in file memcache is not cleared
*No RC entry (Although I did notice a gap in the rc_id field which is kind of
weird, maybe coincidence)
*No dummy edit in page history
*Log entry is missing log_page
*Page table entry is inserted in DB, however page_latest is set to 0, which is
a referential integrity violation and should never happen [The big bad of this
bug]
*Page contents is missing, and replaced with missing revision error. Page
cannot be edited (Get edit conflict warning). Only way to fix page is to
re-upload a new image over it or delete and undelete the page.
Expected behaviour:
*Well you know, upload just works properly ;)
*Referential integrity should never ever be violated. There should never be an
uneditable page.
*Obviously a better behaviour would be for the page to be blank instead of
"broken", however that's probably still a "bad" behaviour. Ideally we would
want the users text to always be on the page. Its unclear to me if we would
prefer that the image totally go away if we can't edit the page properly (ie
the operation totally be atomic), or if the current behaviour of the file being
saved is preferable (probably. Less data loss the better).
*Cache should be cleared so that images don't randomly appear 24 hours after
the fact.
(In reply to Gerrit Notification Bot from comment #33)
> Change 119932 had a related patch set uploaded by Brian Wolff:
> Rollback transactions if job throws an exception.
>
> https://gerrit.wikimedia.org/r/119932
If I'm correct about the cause (Which as it stands is just a guess), and the
patch actually works, what it will cause is that pages experiencing this bug
won't be in a "broken" state (ref integrity failure), but just be blank, so
users can create them later as they please. This is not a full fix to the
issue, we still need to figure out what situation is causing the issue, and
reduce its occurrence (Could someone look at job queue logs for one of the
example files like File:ContentLanguage.svg if logs go back that far, and see
what the last error was?). We also may want to try to catch whatever exception
is happening, and retry the operation, if we're assuming its a very
intermittent issue.
>
> The reasoning for filing it under Security was given in bug 61898 comment 0:
>
> "I'm filing this under Security to keep it on a low radar. They're innocent
> to keep around, but in my experience filing these publicly may cause them to
> disappear at some point when too many people spread the link without proper
> context or try to poke at it."
>
> No comment on the validity of the reasoning, but there are URLs in that bug
> that are not on this one.
That seems unnecessary given how often we're getting new examples - Most
recently [[commons:File:ContentLanguage.svg]] which was uploaded a week ago
(Earlier we seemed to be getting new examples every day). Commons admins also
have db access via tool labs and are more than capable of getting a list of all
affected files themselves if they were so inclined.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
