Page MenuHomePhabricator

Fix some logic in WaitForPreviousBuildStep
ClosedPublic

Authored by epriestley on May 15 2014, 11:35 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Apr 17, 11:15 AM
Unknown Object (File)
Mon, Apr 8, 5:15 PM
Unknown Object (File)
Sat, Apr 6, 2:39 AM
Unknown Object (File)
Mar 4 2024, 7:18 PM
Unknown Object (File)
Feb 15 2024, 3:40 PM
Unknown Object (File)
Feb 15 2024, 3:40 PM
Unknown Object (File)
Feb 12 2024, 9:02 AM
Unknown Object (File)
Feb 5 2024, 3:56 AM
Subscribers

Details

Summary

Fixes T5062. See inlines.

Test Plan

Did not test whatsoever.

Diff Detail

Repository
rP Phabricator
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

epriestley retitled this revision from to Fix some logic in WaitForPreviousBuildStep.
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added a reviewer: hach-que.

Two issues:

  1. Unimported blockers may not be returned.
  2. We may issue a BuildableQuery with an empty list of buildable PHIDs.
src/applications/harbormaster/step/HarbormasterWaitForPreviousBuildStepImplementation.php
68–74

(2) If all the parents are not yet imported...

70

(1) If we add blockers here...

78

(2) ...this will be empty.

83–85

(1) ...we might not return them if we get here.

I can't actually test to see if this fix resolves an issue since it occurs at work, and I won't be back at work until next Wednesday (I work part time).

This scenario should only really occur if $parents returns an empty array, but under what scenario would this be an empty array? (unless it's the first commit in a repo, but I don't think this is the case)

Is it possible the result of 'diffusion.commitparentsquery' is impacted by the new caching code?

hach-que edited edge metadata.

Oh, that explains it :)

This seems good then, I can't test it but the new logic seems trivial enough.

This revision is now accepted and ready to land.May 15 2014, 11:42 AM

I suspect this is occurring because parents have not imported yet.

There is no guarantee that commits are parsed in order, so it's completely expected that a child may fully import, trigger builds, and arrive here before a parent is imported. For example, the parent may be much larger (take longer to import) or encounter a temporary or permanent error.

The parents array will be empty for the first commit in a repository, as well.

(Recent changes haven't caused us to fill the parents array out of cache yet, so behavior on that side should be unchanged.)

(I'll take a shot at at least running this code before I land it.)

I sanity checked this locally, at least.

epriestley updated this revision to Diff 21700.

Closed by commit rP702f073f0a21 (authored by @epriestley).