the user setting up the job may not have access to the Jenkins logs (they may not be an admin) and as such how will they be able to tell that something was wrong with the config (as opposed to a transient issue with GH that should recover?)

After breaking the credentials, accessing the folder configuration triggers an error that reports the connection issue. The same Exception cached in afterSave is also shown.

To help prevent these situations, I suggest adding the ability to perform an early check while editing the credentials JENKINS-76236

to be clear: there is no need to change any folder attribute, but the connection check in afterSave prevents any update (e.g its not the user making a mistake in this form)

(e.g its not the user making a mistake in this form)

the user is choosing the credential (that is invalid) in this form though?

Indeed, it is also possible to create a new folder and select an invalid Credential. In such cases, the field’s validation method correctly reports the selection as invalid (and the stacktrace provides details), yet it is still possible to save the folder.

My statement was based on the steps described in the Jira: first, set up the app and folder correctly, and then modify the credential owner to trigger this issue (IMO where a new validation should be added).
Then, in this scenario, accessing the folder config also shows a failed connection, but with this change, it allows updating any other information.

Please note that afterSave was intentionally swallowing IOExceptions, which cover many error cases (not founds or connectivity issues). However, this IllegalArgumentException is specific to the owner logic and was not included in that catch block.

However, this IllegalArgumentException is specific to the owner logic and was not included in that catch block.

But I think this is important - An IOException is by its nature likely to be transient when talking to remote servers, however IllegalStateException is not and it is (in this case IIUC) saying your page save is rubbish.
Throwing the exception is bad as it results in the angry Jenkins and I am not disagreeing with that part, however I am saying this IllegalStateException is a special case should be caught and then presented to the user in an understandable way say e.g. "The owner for the GitHub Application is invalid for this repository/organisation etc etc..".
Swallowing it and logging, is sweeping an issue with the configuration under the carpet, and is not good UX.

IIRC in this case the IllegalStateException could be transient (and easily fixed with the reported error), and its not related to jenkins confs. This is not coming from the folder configuration itself but rather from the credential (just to reiterate) when the app is not installed (or have been removed) in the selected credential owner.
It’s not a Jenkins internal state issue, but rather related to the installation status of the app on GitHub (which the error gives a hint on how to fix it).

We may want to prevent folder creation in these scenarios. However, for folders that were previously working but have since lost their connection, it seems reasonable to allow updates to fields like the description (for example, to indicate “don’t use this anymore”).