Really I do not think this method should even be `@Exported` at all, since for any large installation it is never safe to call it from the REST API. The method itself is harmless because it returns a lazy list (using merge sort to collate builds from the various jobs in reverse chronological order, filtering the result according to the build node). But it is the responsibility of the caller to either display its results incrementally (with the option to cancel); or call `limit` to ensure that not too many results are produced, which is what many REST API calls do.

It would be incompatible to add a `limit` call to the existing method; you would need to introduce a new method just to be `@Exported(name="builds")`. But even `limit(1)` here does not guarantee that you will not load every build record in the system: it continues loading builds until it finds a sufficient number from this node, but there is no way of knowing in advance if or when such a build will be found. There might be no builds from this node, ever, or there might be some from months back, but in the meantime you are causing a ruinous performance problem on the server looking for them: Jenkins has no regular database of build records that could be searched by various indices.

I think #1154 just needs to be reverted completely. There is no safe way to expose this information from the Jenkins REST API, because this medium offers no mechanism of sending incremental results. Modern REST services typically include a pagination feature available uniformly across all queries, with a page size of 100 entries or so, and the caller must explicitly request subsequent pages when it is indicated that a result has been truncated. Usually some kind of rate throttling is also implemented to prevent (accidental or malicious) denials of service. But Stapler’s bean exporting does not currently support this mode. And even if it did, a special output format would be required to serve things like filtered `RunList`s, in which every _candidate_ entry (`Run` in this case) would be given an index for purposes of pagination, but most (in this case builds from other nodes) would be represented as a special “filtered out” entry, so that the client could see that entries 201–300 included 17 builds from this node (with full details) and 83 builds from other nodes (with details omitted).