Probably not a defect at all. Builds run with the build step are not considered “downstream”, and probably would not be even with JENKINS-29913, since the dependency graph is static. So DownstreamBuildSelector makes no sense in this context, and this is already logged.

I think you just want to use SpecificBuildSelector. And you need to save the return value of the build step so you can access its .number.

jglick strange. Using the 'build' DSL syntax does log the following:

Started by upstream project "HyperLynxAS/units/HyperLynxAS/Common" build number 277

And I do see the following in the build.xml:

    <hudson.model.CauseAction>
      <causes>
        <hudson.model.Cause_-UpstreamCause>
          <upstreamProject>a</upstreamProject>
          <upstreamUrl>job/a</upstreamUrl>
          <upstreamBuild>286</upstreamBuild>
          <upstreamCauses>
            <hudson.model.Cause_-UserIdCause/>
          </upstreamCauses>
        </hudson.model.Cause_-UpstreamCause>
      </causes>
    </hudson.model.CauseAction>

Is this really not considered "downstream"? Yes - I also tried SpecificBuildSelector and while that may work in my scenario, my downstream jobs are called recursively, making passing specific build numbers much more challenging.

apemberton from the perspective of the downstream build there is indeed an UpstreamCause. But the upstream/downstream relationships are specific to AbstractProject. UpstreamCause is only considered by TriggeredBuildSelector, which is in the wrong direction for this use case.

Anyway as the PR demonstrates, SpecificBuildSelector is all you need, and is much more straightforward and reliable than trying to make Jenkins infer the right build number: you have it right in front of you.

Really from Pipeline I would advocate only using SpecificBuildSelector, and where we need to introduce general-purpose Pipeline tools to introspect related projects & builds, like JENKINS-31576, we can do that.

Is this really not considered "downstream"?

Actually, no. Among the many confusing things about Jenkins’ dependency graph is the fact that merely having an UpstreamCause does not suffice. The formal upstream/downstream build relationship presupposes a static project relationship, and then picks a particular build via fingerprint matches, not causes.

my downstream jobs are called recursively

Not quite sure what you mean, but this statement just makes me even less inclined to trust any magical build number determination Jenkins might make. Track the exact numbers of the builds you started and request them. You can pretty easily pass data from an upstream Pipeline build to a downstream build of any type (using parameters), and you can easily pass data (other than its own build number, which is obvious) from a downstream Pipeline build to an upstream Pipeline build (using .buildVariables); a downstream freestyle project could do so with various plugins perhaps.

Code changed in jenkins
User: Jesse Glick
Path:
pom.xml
src/test/java/hudson/plugins/copyartifact/CopyArtifactWorkflowTest.java
http://jenkins-ci.org/commit/copyartifact-plugin/12e65070887b67eb5c65bd88c2cb84153fa4b78d
Log:
JENKINS-33577 Demonstrate that SpecificBuildSelector suffices to copy artifacts from a build downstream of a Pipeline build.

Code changed in jenkins
User: ikedam
Path:
pom.xml
src/test/java/hudson/plugins/copyartifact/CopyArtifactWorkflowTest.java
http://jenkins-ci.org/commit/copyartifact-plugin/c7f1b412f535435948f9b9ccc73f5162d6a73225
Log:
Merge pull request #80 from jglick/workflow-copyFromDownstreamBuild-JENKINS-33577

JENKINS-33577 Demonstration test

Compare: https://github.com/jenkinsci/copyartifact-plugin/compare/1f34b2557f8b...c7f1b412f535