We noticed one of our Jenkins controllers was consuming enormous amounts of CPU and RAM. We eventually traced it to runs that had archived symbolic link loops, causing fetches of /wfapi/artifacts to take "forever", waste precious resources and generally make the JVM (and thus Jenkins) totally unresponsive.

Given the plugin's documentation calls out a feature that's apparently designed to prevent this (introduced due to JENKINS-34791 via jenkinsci/pipeline-stage-view-plugin#14: Properties to configure hardcoded limits on APIs - JENKINS-34791 by svanoort):

• Artifacts shown per run (default: 100) - com.cloudbees.workflow.rest.external.RunExt.maxArtifactsCount

...I was quite surprised to see that this feature/configuration had been not only implemented for another part of the code, but also mostly removed via jenkinsci/pipeline-stage-view-plugin#208: Optimize check for artifacts by jglick.

Granted, it was a mistake to create symbolic links in the archive (an unfortunate conflict between two features offered by our pipeline library), however the fact that such a mistake had the ability to take out our Jenkins controller is what worries me.

Besides, from what I can tell, that REST API endpoint appears to be invoked to render a tooltip when hovering over runs in the run/stage table:

...and I question the value of generating such a "tooltip" containing more than 100 entries, anyway.

I therefore would like to suggest that RunAPI#doArtifacts() be modified to check the value of the previously-documented maxArtifactsCount property (defaulting to Integer#MAX_VALUE if unspecified) and instead call Run#getArtifactsUpTo() with the value. Or add a new property if we don't want to break anybody previously using the old one (it might make more sense to add it - and scope it! - to the RunAPI class).

This could also help explain the behaviour observed in JENKINS-72583.