BlockVolumeService.update(String volumeId, String name, String description) is used to set the name and description on a (Cinder) Volume.
This results in a JSON request being HTTP PUT to OpenStack containing the new name & description ... but it also includes os-vol-mig-status-attr:migstat = none with the rest of the JSON request, and the "Rocky" version of Cinder rejects that request:

ActionResponse{success=false, fault=Invalid input for field/attribute volume. Value: {u'description': u'...', u'display_name': u'...', u'name': u'...', u'os-vol-mig-status-attr:migstat': u'none', u'display_description': u'...'}. Additional properties are not allowed (u'os-vol-mig-status-attr:migstat' was unexpected), code=400}

i.e. the update method sets the name & display_name attributes to the String name it was given, and both the description & display_description attributes to the String description it was given, but it also tries to set attribute os-vol-mig-status-attr:migstat to none, which fails.

From what I've seen thus far, the underlying cause appears to be that CinderVolume.getMigrateStatus() does not return null if it has not been set; this then causes the JSON code to mistakenly believe it should be included in the outgoing request ... which causes Cinder to reject the (invalid) request.
According to the javadocs, this field's default value should be null, but the existing implementation returns a default value of MigrationStatus.NONE instead of null.

i.e. it's not working as documented & it isn't working; this is probably cause & effect.

Note: The "Pike" version of Cinder doesn't seem to care about this and does not reject the request, allowing this issue to remain undetected for so long; the "Rocky" version does care and does reject it; I don't know about the "Queen" version.
Note also: The openstack4j has had numerous similar bugs in the past. e.g. ContainX/openstack4j #932, #869, #823, #820, #682, #606, #573, #470.