Major It seems that `?tree=allBuilds[number]{0,1}` unconditionally forces Jenkins to load all builds into memory. If the number of builds is large this can denial-of-service your Jenkins instance.
Steps to reproduce:
- Find a Jenkins instance with a job that has a very long history
- Verify that the standard REST query (for 100 jobs) executes quickly. For example: https://example.com/jenkins/job/my-job/api/json
- Now run https://example.com/jenkins/job/my-job/api/json?tree=allBuilds[number]{0,1}
Expected result: It runs fast
Actual result: Jenkins goes out to lunch.
[JENKINS-49908] allBuilds eagerly loads every build into memory before applying pagination
Edward Yang
added a comment - Thanks for confirming the issue.
I am also curious: if I specify a "tree" parameter with a parameter that is only visible at depth=2 as opposed to depth=1, does Jenkins load all of "depth=2" into memory before applying the filter? I saw some empirical results which suggested this might be the case, although the signal was a bit weaker in this case.
Edward Yang
added a comment - Thanks for confirming the issue.
I am also curious: if I specify a "tree" parameter with a parameter that is only visible at depth=2 as opposed to depth=1, does Jenkins load all of "depth=2" into memory before applying the filter? I saw some empirical results which suggested this might be the case, although the signal was a bit weaker in this case. 
Ulysses Wu
added a comment - tree=builds API only returns 100 latest results
And tree=allBuilds API is extremely slow when you have a lot of builds in history
Problem is not solved for 4 yrs+
good job jenkins 
Ulysses Wu
added a comment - tree=builds API only returns 100 latest results
And tree=allBuilds API is extremely slow when you have a lot of builds in history
Problem is not solved for 4 yrs+
good job jenkins 
Yes, filters are being applied after polling the data.
We were talking about issue in the context of adding a new query language at last Jenkins World contributor summit, but it's not there yet