Since the "that then needs to be caught by whatever does the registering" is already happening, maybe the currently working approach should just be officially documented:

try {
	... // Something that could also throw a RejectedAccessException
} catch (e) {
	... // Do something due to the failure or based on the failure like sending a notification email

	// While there would be no need to re-throw the exception to propagate the error (because the build result must be set
	// to failure for email-ext anyhow before), re-throw it for e.g. script approval requests:
	throw e
}

should just be officially documented

Who reads documentation?

(Tongue in cheek)

Possibly I could just make ScriptApproval.accessRejected be automatic at the throw site

Actually I cannot—there is no ApprovalContext. Therefore I consider this purely a bug in workflow-cps. Unclear if there is only one mechanism by which this problem might occur, or several.

…though if GroovySandbox had an API to set a thread-local ApprovalContext, to be used from StaticWhitelist.blacklist, then SandboxContinuable could pass this rather than inspecting the Outcome, probably increasing reliability.

abayer Could you please TAL?

Only thing that comes to mind at first glance is maybe having SandboxContinuable#findRejectedAccessException actually traverse the flow graph looking for a RejectedAccessException anywhere? Though I guess that wouldn't actually show up there if it's caught, which is the whole problem here.

The minimal test case (thanks to abayer in JENKINS-40333) is

catchError {Jenkins.instance}

From inspecting the issue in a debugger, it is clear that Continuable.run0 is simply too coarse-grained for this purpose: it is designed to keep stepping through the program until it needs to yield, whereas a RejectedAccessException could be thrown and caught inside a single CPS VM chunk.

So I am again looking into deprecating ScriptApproval.accessRejected and just making the approval entry addition be automatic at the call site. This will require a new API which callers like workflow-cps would need to opt in to. At the same time I think I could move ScriptApprovalNote into script-security so it would be available for all plugins, not just Pipeline. The net effect would be an API that it is both easier to use and more reliable.

I will note that I was using a Jenkins pipeline and was having this issue when putting scripts in the Jenkins "failure" block, though not within a catch. It would seem that the "failure" block is implicitly a catch block. The workaround for me was running the script arbitrarily in one of the steps of the pipeline, so that it would come up in script approval, then moving it back to the failure block.

Same thing happens when the rejected code is in the initialization code to give a @Field its value.  I suspect it becomes a static variable and the exception gets swallowed because its in the initialization for the class or called from inside, so to speak, the constructor.

I used a line like this at the top of the script

@Field List<String> list = [''] * 21