Page MenuHomePhabricator

Add controllers/search/edit engine functionality to RepositoryIdentity
ClosedPublic

Authored by amckinley on May 5 2018, 3:23 AM.
Tags
None
Referenced Files
F14083846: D19429.diff
Sat, Nov 23, 5:42 AM
Unknown Object (File)
Wed, Nov 20, 10:16 PM
Unknown Object (File)
Sun, Nov 17, 10:05 AM
Unknown Object (File)
Thu, Oct 31, 9:57 PM
Unknown Object (File)
Oct 17 2024, 3:17 AM
Unknown Object (File)
Oct 16 2024, 8:23 AM
Unknown Object (File)
Oct 9 2024, 9:34 AM
Unknown Object (File)
Oct 9 2024, 9:34 AM
Subscribers
Restricted Owners Package

Details

Summary

Depends on D19423. Ref T12164. Adds controllers capable of listing and editing PhabricatorRepositoryIdentity objects. Starts creating those objects when commits are parsed.

Test Plan

Reparsed some revisions, observed objects getting created in the database. Altered some Identity objects using the controllers and observed effects in the database. No attempts made to validate behavior under "challenging" author/committer strings.

Diff Detail

Repository
rP Phabricator
Branch
repo-id-2
Lint
Lint Passed
SeverityLocationCodeMessage
Advicesrc/applications/repository/storage/PhabricatorRepositoryIdentity.php:58XHP16TODO Comment
Unit
Tests Passed
Build Status
Buildable 20312
Build 27577: Run Core Tests
Build 27576: arc lint + arc unit

Event Timeline

Owners added a subscriber: Restricted Owners Package.May 5 2018, 3:23 AM

This all looks great to me, with one minor inline about possible race behavior.

src/applications/repository/worker/commitmessageparser/PhabricatorRepositoryCommitMessageParserWorker.php
80

There is some possibility that this save() could race, if two workers are parsing different commits by the same author:

  • Both look for the Identity and don't find it.
  • Both build a new Identity and save it.
  • Whichever one is slower loses.

In this case, the slower INSERT will hit AphrontDuplicateKeyQueryException when the second row collides with the first row on the UNIQUE KEY on nameHash.

I don't have a great solution for this. Where it comes up elsewhere, I think we usually use this pattern:

thing = load(id);
if (!thing) {
  thing = new(id);
  try {
    thing->save();
  } catch (duplicate) {
    thing = load(id);
    if (!thing) {
      throw new Exception("Raced and lost, then failed to load the object we lost the race to? Very confusing.");
    }
  }
}

This doesn't feel very elegant, but should survive anything reasonable.

This revision is now accepted and ready to land.May 5 2018, 3:31 PM

No attempts made to validate behavior under "challenging" author/committer strings.

This doesn't need to be vetted too heavily, no install has actually managed to produce any of these so far that I'm aware of (although I'm just sure one will some day) and I'm pretty confident this pattern works (if it doesn't, we'll have to fix a few other things too).

Also, if workers do race the one that lost the race should just retry, so the race is harmless, just not ideal (and will stick a potentially confusing error in the error log).

remove ferret implementation

This revision was automatically updated to reflect the committed changes.