gerritbot added a comment.
Change 270777 merged by jenkins-bot:
Simplify SpecialSetLabelDescriptionAliases after ChangeOps fix
https://gerrit.wikimedia.org/r/270777
TASK DETAIL
https://phabricator.wikimedia.org/T121395
EMAIL PREFERENCES
gerritbot added a comment.
Change 270777 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Simplify SpecialSetLabelDescriptionAliases after ChangeOps fix
https://gerrit.wikimedia.org/r/270777
TASK DETAIL
https://phabricator.wikimedia.org/T121395
EMAIL PREFERENCES
gerritbot added a comment.
Change 260585 abandoned by Aude:
Use common baserevid for label and description changes [WIP]
Reason:
we probably want to ultimately solve this by having one api request
(wbeditentity), but then the edit summaries might not be as fine-grained as
they are now.
gerritbot added a comment.
Change 269718 merged by jenkins-bot:
Make SpecialSetLabelDescriptionAliases use ChangeOps.
https://gerrit.wikimedia.org/r/269718
TASK DETAIL
https://phabricator.wikimedia.org/T121395
EMAIL PREFERENCES
gerritbot added a comment.
Change 269718 had a related patch set uploaded (by Daniel Kinzler):
Make SpecialSetLabelDescriptionAliases use ChangeOps.
https://gerrit.wikimedia.org/r/269718
TASK DETAIL
https://phabricator.wikimedia.org/T121395
EMAIL PREFERENCES
daniel added a comment.
Turns out SpecialSetLabelDescriptionAliases also needed fixing
TASK DETAIL
https://phabricator.wikimedia.org/T121395
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: daniel
Cc: thiemowmde, gerritbot, Bene, Lydia_Pintscher,
gerritbot added a comment.
Change 269461 merged by jenkins-bot:
Make ChangeOp::validate run against the current revision.
https://gerrit.wikimedia.org/r/269461
TASK DETAIL
https://phabricator.wikimedia.org/T121395
EMAIL PREFERENCES
gerritbot added a comment.
Change 269461 had a related patch set uploaded (by Daniel Kinzler):
Make ChangeOp::validate run against the current revision.
https://gerrit.wikimedia.org/r/269461
TASK DETAIL
https://phabricator.wikimedia.org/T121395
EMAIL PREFERENCES
daniel added a comment.
In https://phabricator.wikimedia.org/T121395#2008222, @aude wrote:
> @daniel hmm... Using the latest base revision would definitely help, though
> wonder if relying on that, we still might have a race condition.
For two concurrent API requests, there is a race
aude added a comment.
@daniel hmm... Using the latest base revision would definitely help, though
wonder if relying on that, we still might have a race condition.
TASK DETAIL
https://phabricator.wikimedia.org/T121395
EMAIL PREFERENCES
aude added a comment.
@daniel using the latest revision for validating sounds ok.
also, per https://phabricator.wikimedia.org/T121395#1898302 (and really wonder
how I was unclear there?), if there is an edit conflict, then the patch /
result of resolving the conflict should be validated
daniel added a comment.
Suspicion (1) seems to be unfounded:
- api/EditEntity calls ModifyEntity::applyChangeOp on a ChangeOps object.
- ModifyEntity::applyChangeOp calls ChangeOp(s)::validate
- For each ChangeOp a ChangeOps instances contains, ChangeOps::validate will
first call validate on
thiemowmde added a subscriber: thiemowmde.
thiemowmde added a comment.
We discussed this during todays story time. Suspicions:
1. With one API request (or two with no explicit base revision), both ChangeOps
are first validated independently, and then applied. The second is validated
without
gerritbot added a subscriber: gerritbot.
gerritbot added a comment.
Change 260585 had a related patch set uploaded (by Aude):
Use common baserevid for label and description changes [WIP]
https://gerrit.wikimedia.org/r/260585
TASK DETAIL
https://phabricator.wikimedia.org/T121395
EMAIL
aude added a comment.
problem is that (in some cases) we are validating an old version of an entity,
with a specific change (label or description) patched into the entity.
the api call keeps passing the same baserevid even after subsequent edits in
the term box. ModifyEntity uses baserevid
aude added a comment.
to fix in the backend, one possible solution might be to generate changeops for
the edit conflict patch, and apply validation at this point.
https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/master/repo/includes/EditEntity.php#L440
(probably some of this
aude added a comment.
i can reproduce the issue and looking into this
TASK DETAIL
https://phabricator.wikimedia.org/T121395
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: aude
Cc: Bene, Lydia_Pintscher, hoo, aude, Aklapper, daniel, Jonas,
aude added a comment.
see:
https://www.wikidata.org/w/index.php?title=Q4115189=284854784
https://www.wikidata.org/w/index.php?title=Q3737270=283412652
TASK DETAIL
https://phabricator.wikimedia.org/T121395
EMAIL PREFERENCES
aude added a comment.
i suspect this is (unfortunately) a case where we run in to limitations of
TermSqlIndex and maxConflicts it finds:
* @note: This implementation does not guarantee that all matches are returned.
* The maximum number of conflicts returned is controlled by
Bene added a subscriber: Bene.
Bene added a comment.
Both items have their labels tracked correctly in the `wb_terms` table.
select * from wb_terms where term_entity_id in (3737270, 4115189) and
term_language = 'en'
TASK DETAIL
https://phabricator.wikimedia.org/T121395
EMAIL PREFERENCES
20 matches
Mail list logo
