As a reminder, removing this line will default the selection to the first element in LocationTypeCode,list() (which is DEPOT)

Removing this property means that the first one from the list is picked automatically or how is it working right now?

yeah that's right. The first element of LocationTypeCode.list(), which is DEPOT. I can undo this change if we want, but not selecting a value throws us to an ugly error page

Thinking about this more, I would actually prefer the default to be empty and for the form submission to return and display a validation error for blank/null.

Can you post a screenshot of the ugly page (I assume this is the exception stacktrace) so I can figure out the best way to handle it?

I agree it's probably better to default to empty and just handle the error better.

This is old gsp pages though so I don't know the best way to do that. Do we even have nice error handling at all for these pages? If it's not a simple fix, maybe it's fine to just leave it with the messy error given that the goal is to eventually migrate everything over to react... idk

@ewaterman the reason for such error is that the data services throw validation exception when validation didn't pass.
It works the same way as the .save(failOnError: true) would work.
Regular .save() returns null if the validation didn't pass.
On GSP pages we usually tend to handle such cases like that:

if (x.validate() && x.save()) {
  render(view: ...)
  return
}
// If error occured
render(view: ...)

and then inside view:

<g:hasErrors bean="${x}">
            <div class="errors" role="alert" aria-label="error-message">
                <g:renderErrors bean="${x}" as="list" />
            </div>
</g:hasErrors>

and the errors are listed in user-friendly way.

Since data service's .save() throws en error, you'd have to wrap that in try/catch clause instead, but I'm not a fan of try/catch clause, because there were some inconsistencies in transaction rollback, but I do not remember now if it was Grails 1 or Grails 3 thing (would have to find our discussions from the past).

Thanks for the detailed explanation. I looked into it and it's actually a really simple fix. It does have the frontend error processing that you suggested Kacper. The thing that was missing was the x.validate() step. Changing the code to the following works:

if (locationTypeInstance.validate() && locationTypeDataService.save(locationTypeInstance)) {
    flash.message = "${warehouse.message(code: 'default.updated.message', args: [...])}"
    redirect(action: "list", id: locationTypeInstance.id)
}
else {
    render(view: "edit", model: [locationTypeInstance: locationTypeInstance])
}