Page MenuHomePhabricator

re-flagging causes old templates/files to be used sometimes
Closed, ResolvedPublic

Description

Author: saibotrash

Description:
https://de.wikipedia.org/w/index.php?title=Spezial:Logbuch&page=Roy+Worters&hide_review_log=0

Times UTC+1, article viewing not logged-in(!)

  • before 2011-12-23T20:35:29: the images were mis-oriented since the flaged revisions setup froze article and showed the old file versions (which are in two templates on bottom of the article).
  • 2011-12-23T20:35:31 I removed and set the flag for the last version. The files show up correctly afterwards.
  • 2011-12-23T20:38:12 NowCommons-Sichtbot reflagged the last revision.

Images were mis-oriented again although it would be expected that the keep showing the current file versions like before. This is the flaggedrevs bug this report is about.


Version: unspecified
Severity: minor

Details

Reference
bz33353
ReferenceSource BranchDest BranchAuthorTitle
repos/cloud/toolforge/jobs-cli!15bump_to_16.0.2maindcarod/changelog: bump to 16.0.2
repos/cloud/toolforge/jobs-cli!12wrap_buildservicemaindcarorun: add filelog to buildservice if passed
repos/cloud/toolforge/jobs-api!61wrap_buildservicemaindcaro[command] wrap buildservice with a shell
repos/cloud/toolforge/builds-api!76alerts_when_quota_is_getting_used_upmainraymond-ndibe[builds-api] alert when quota usage is over 90%
repos/cloud/toolforge/toolforge-deploy!164bump_jobs-apimainproject_1317_bot_df3177307bed93c3f34e421e26c86e38jobs-api: bump to 0.0.254-20240108102443-2737a5d0
repos/cloud/toolforge/jobs-cli!8main-I50f4dcfac0ebc5ae708fb0d4e7e8131e8503aebdmaintaaviAllow enabling filelog with buildpack images
repos/security/semgrep-merge-tool!5T353536-add-rule-exclude-functionalitymainsbassettAdd semgrep rule exclude functionality
repos/cloud/toolforge/jobs-api!51main-I581bae903659a41a746e2064646e3010cec324b5maintaaviapi: allow file logging on build service jobs with all mounts
repos/cloud/toolforge/jobs-api!50main-I8fa677536982cd7134cdc4de01ac490207004269maintaavicommand: Always use absolute paths for file logs
repos/security/gitlab-ci-security-templates!30T353534-gosec-refactormainsbassettRefactor golang-gosec CI include
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:07 AM
bzimport set Reference to bz33353.
bzimport added a subscriber: Unknown Object (MLST).

I assume the bot edits via the API, which always uses the current versions. In that case, the only issue could be some sort of outdated cache of what current templates/files and revision of a page uses.

The misbehaviour not only happened in this single case but is easily reproduceable in at least a dozen examples.

Procedure:

  • Latest version of article is flagged.
  • Included image is changed at commons, or locally deleted and so included from commons for now on.
  • Article keeps link to old image.

So far so good.

  • Article is flagged again via API, logentry is created.

In nearly all cases the image is displayed correctly now.

In _some_ cases:

  • Article shows image wrong.
  • Via web UI remove flag and set flag again.
  • Article shows image right.
  • Via API set flag again, logentry is created.
  • Article shows image wrong.
  • ...repeat

In all cases I speak of "flag" or "unflag", I am speaking of flagging or unflagging _the same version_ of the article, which is the top version.

So in some cases via API, although the flagging of the top version of an article creates a log entry saying that the top version of the artcle was flagged again, the web UI (for not-logged-in users) shows an older version of included images.

This all does happen only in some cases I don't see any pattern in.
The only escape seems to be to create a new version; a zero-edit doesn't help, too.

If you review pages on diffs with diffonly=1 do you get similar problems as with reviewing via API?

No, this has never been observed, and is not reproducable.

The problem only arises if you review again a version that is already reviewed, which is only possible via the API, as the web interface doesn't show the neccessary button (only grayed and not pushable).

Fixed in r112773 (not live).