When a job is run, the Perforce plugin for Jenkins records a changelist number for the build instance. From that point forward, triggering additional builds via Perforce only happens when new changelists are submitted with numbers higher than the recorded changelist number. Great, except that the recorded changelist number may not be correct.

For example, if the most recent changelists look like this (from "p4 changelists -m 2"):
Change 24083 on 2012/05/23 by rmercer@rmercer-DcsMain pending 'The adapter layer now returns D'
Change 24082 on 2012/05/23 by reladmin@jenkins-aci-RILCinterion-QA-2 'Check in server build result fo'

and a build starts (either via the Build Now button, or because of 24082 being submitted), the Perforce plugin runs "p4 counter change" and records 24083 as the changelist number. Note that 24083 is a pending changelist.

Further polling will fail to detect that 24083 was submitted. No build will result. Oops, the latest "reserved" changelist number was recorded, rather than the latest "submitted" changelist number.

Often this problem is masked because new changelist numbers get generated upon a checkin, but not always. Perforce only renumbers a changelist upon checkin if there are intervening changelists.

Suggested solution: Rather than using "p4 counter change" to detect the current changelist number, please use "p4 changelists -m 1 -s submitted".