Hello!

We are currently experiencing an issue with the P4 Plugin where SCM polling gets stuck trying to look for changes from a build that has failed or has been aborted due to a timeout. An example of this being:

P4: Polling with range: 245698,245690...
p4 changes -m100 //workspace/...@245698,245690

where changelist 245690 represents the build that aborted due to a timeout. It's worth pointing out that there were two additional changes in-between CL245690 and CL245698, none of which triggered a new build via polling. Triggering new builds manually also did not resolve the SCM polling issue as it continued to search for changes from latest until 245690. It fixed itself after a while and started looking for changes from 'now', but I could not tell you which conditions resolved that. Why is it searching for changes starting from a higher changelist up until a lower changelist? It seems incorrect, but I'd be happy to proven wrong

This issue became more prevalent when we transitioned our syncing logic to a Jenkins shared library (see attached screenshot of the library settings). Previously, we had our syncing logic embedded in each pipeline script, but there is nothing functionally different between the two versions. In terms of frequency, we're seeing this issue appear almost daily, but the common pattern is when a build fails or aborts, polling gets stuck. Oddly enough, it's also worth bringing up that this issue has only appeared on 1 out of 3 jobs that have transitioned fully to using the shared library; the other 2 jobs have been running fine without any issues whatsoever. It's really strange to us!

// syncPerforce.groovy
def call() {
    def changelistToUse = ''
    if (env.CHANGELIST_TO_BUILD != null) {
        changelistToUse = env.CHANGELIST_TO_BUILD
        echo "Syncing to changelist ${changelistToUse} on ${env.NODE_NAME}"
    }
    else {
        echo "Syncing to latest changelist on ${env.NODE_NAME}"
    }

    // Retry up to three times when checking out from Perforce due to intermittent connection errors.
    retry (3) {
        checkout perforce(
            credential: '<redacted>', 
            filter: [userFilter(user:'<redacted>')], 
            populate: syncOnly(
                force: false, 
                have: true, 
                modtime: false, 
                parallel: [enable: false, minbytes: '1024', minfiles: '1', threads: '4'], 
                pin: changelistToUse, 
                quiet: false, 
                revert: true), 
            workspace: streamSpec(
                charset: 'none', 
                format: "jenkins-${env.NODE_NAME}-" + env.JENKINS_WORKSPACE_NAME,
                pinHost: false, 
                streamName: env.JENKINS_STREAM_PATH
            )
        )
   
        if(env.CHANGELIST_TO_BUILD == null) {
            env.CHANGELIST_TO_BUILD = "${env.P4_CHANGELIST}"
        }
    }
} 

Reverting the syncing logic to be embedded in the pipeline script has appeared to alleviate our problems for now, but I'd like to understand the root cause behind this. Why does the P4 plugin continuously look for changes up to the failed/aborted build, even after a new build has been triggered that pins the workspace to the latest changelist?