Page MenuHomePhabricator

Revision stuck in importing (after phabricator upgrade)
Closed, ResolvedPublic

Description

After a phabricator upgrade this morning, commits are no longer importing. We were running a commit from about a month ago previously. We are using phabricator hosted git repositories with Herald rules triggered on commit.

I see no errors since daemon start in /var/tmp/phd/log/daemons.log. All checkboxes green on repository status page. Forcing a repository update does not help.

./bin/repository importing ZU shows:
rZU68059b3473d53c28e4ddffb3cd0bac79ed719fbb Herald
rZU011a6af20dac1cae5efc9ab191645248f315e85e Herald

Not sure how to get them unstuck from that state.

Event Timeline

austinf raised the priority of this task from to Needs Triage.
austinf updated the task description. (Show Details)
austinf added a subscriber: austinf.

The Herald rule appears to have completed fine as well.

Actions Taken
Trigger an Audit by: Everest
Conditions were met for H1 Everest Review·Outcome: Triggered an audit.
Rule Details
Everest Review
✓ Condition: Repository's projects include all of Everest
✓ Condition: Differential revision does not exist
✓ Condition: Commit's branches contains master
PASSAll conditions matched.

Is it a single revision or any new commit? What is your update workflow, do you use our scripts?

Looks like any new commit. Adapted your script from here https://secure.phabricator.com/book/phabricator/article/installation_guide/#updating-phabricator to work on our system. We use systemd to manage stopping and starting daemons is the only difference.

Can you try --trace and paste the output?

Support Impact several people have has issues this week after upgrading.

we seem to reproduce this here now on at least a few commits.

Does anyone have any errors in their log?

./bin/phd log
./bin/phd log --limit 10000  #look back further if nothing useful

iiam

No errors in log there either, running ./bin/repository importing ZU --trace just gives the query:

>>> [2] <connect> phabricator_repository
<<< [2] <connect> 1,219 us
>>> [3] <query> SELECT * FROM `repository` r  WHERE (r.callsign IN ('ZU')) ORDER BY r.id DESC
<<< [3] <query> 385 us
>>> [4] <query> SELECT repositoryID, commitIdentifier, importStatus FROM `repository_commit`
        WHERE repositoryID IN (333) AND (importStatus & 15) != 15
<<< [4] <query> 2,382 us
rZU68059b3473d53c28e4ddffb3cd0bac79ed719fbb Herald
rZU011a6af20dac1cae5efc9ab191645248f315e85e Herald

Well, I think I solved the mystery... See D10723.

Awesome, thanks for the quick fix. Can you tell me how to make it re-parse commits that are stuck?

This is now fixed. See rPe6d946661ddf296d44063f12e44925a35271cc6f for an example that was broken on this install and subsequently fixed.

If you have any commits impacted by this, please run

scripts/repository/reparse.php --herald rXnnnnn

to fix it. Note you will see some duplicate transactions but at least the commit will be fully imported.