thank you for your answer
i´m not speaking of the initial configuration but of editing a working configuration. so all values should be defined fine. i guess it might be a timing issue where the request is triggered before the managerDN value is assigned to the form field.
i didn´t check the code but it sounds plausible to me that, while looping through all currend values that have to be assigned the form fields, the verification request is triggered as soon as the server url value is assigned, while the managerDN value yet isn´t. so the method that generates the url to be requestet reads the value out of the managerDN field that is still empty.
in this case the solution would be to delay the generation of the request url to a point where all values where assigned to their form fields.
in reference to your suggested workaround it would probably also solve our problem to simply reverse the loop that assignes the initial form values, so that the managerDN field is filled before the url field. on the other hand this could affect other requests that might rely on the current assignment order.
also i guess it would mask the issue to trigger the verification request when the managerDN value is assigned as well. this should result in two requests where the first failes while the second is successful and thereby hides the fail of the first attempt. you might want to consider doing so anyway as this would also result in reflecting changes done to the managerDN field. as right now the changes done to managerDN are not "live-tested" in the way that changes to the url it self are.
By the time the request is made, the field value was not yet been set by you, so the error message is correct about that. And it just doesn't update when changing a different field.
Workaround: Start with auth, then only fill in server.