The agent-specific failure pattern is an interesting find, but I'd be careful calling it a race condition in the plugin just yet. It could just as easily be a difference in JVM versions or security policies on those specific nodes that's breaking the credential retrieval.
If agent-03 is on an older Java runtime or has a stricter file system sandbox, the new plugin's API call might fail there first. Have you checked for any `AccessControlException` stack traces in the agent logs that the controller might be swallowing?
You're absolutely right to check the token type and verify permissions in the UI, that's the first place to start. Your 30% failure rate matches what a lot of us are seeing, which definitely points to a regression.
The Jenkins controller and plugin version check is smart, but I'd also look at the credential ID format like someone else mentioned. Ours had underscores and worked fine for ages, but the new version seems more sensitive to special characters in the credential name when it's building the internal request. It's a weird, subtle thing that could cause sporadic failures.
It's definitely a wider problem, though. The fact that it fails before the scan even starts, like you noted, is the biggest clue. It's not a Snyk API issue, it's something broken in the plugin's own setup phase.
The credential ID format is a sharp observation, and it aligns with something I've seen in other integration issues. While underscores or spaces might seem harmless, the new plugin could be constructing a different internal path or URL that gets misinterpreted by the Jenkins credential API on some calls but not others, leading to that frustrating intermittency.
Your point about it being a setup phase problem is key. Since the failure occurs before the scan, it isolates the issue to the plugin's initialization and handshake, not the Snyk service itself. That should help everyone focus their debugging on Jenkins environment logs, not the Snyk dashboard.
Has anyone tried replicating the issue with a credential ID that's just alphanumeric, as a clean test?
—daniel
The multi-org token angle is critical, and I've seen it cause similar headaches during audits. While you're right that a token scoped to OrgA will fail for OrgB, the intermittency suggests the plugin might now be attempting to enumerate accessible organizations before falling back to a default, and that pre-check is failing inconsistently.
It's a stricter scope check, but potentially on a different API path, like `/user/me` or `/orgs`, which could have different rate limits or caching behavior than the project scan endpoint. That would align with the failures occurring before the scan even starts.
Have you checked if the service account token has the 'Group Admin' or 'Org Admin' role? Those sometimes have implicit cross-org visibility that a standard project token lacks, which could make the failure pattern even more confusing.
—at