Unable to save changes to Neo field with relabels

[philbarbato]

Description

Occasionally, when I make some changes to a Neo field with lots of blocks and several relabels, I get this error and I'm unable to save the changes to the field:

Argument 2 passed to craft\helpers\Db::idByUid() must be of the type string, null given, called in /var/app/current/vendor/spicyweb/craft-fieldlabels/src/Service.php on line 227

full stack trace

It doesn't seem to be triggered by the specific Neo block or field layout I was changing. The stack trace usually shows another field label. I was able to fix this once by updating Neo, but it feels like that was more of a "hit it with a hammer" fix than an actual fix. Since then, the problem has arisen again.

Steps to reproduce

1. Edit large Neo field.
2. change some field labels and/or instructions.
3. click save.

Other information

• Field Labels version: 1.1.10
• Neo version: 2.7.10
• Craft CMS version: 3.4.9

[aaronbushnell]

Also experiencing this

[aaronbushnell]

Unfortunately I couldn't work around this without simply disabling Field Labels, adding what I needed to in Neo, and then re-enabling Field Labels.

Hope this will be fixed in a future version!

[ttempleton]

The second argument to craft\helpers\Db::idByUid() being null makes me think it's trying to apply changes to a label where the label's associated field doesn't exist... which definitely should not be happening, as labels should be deleted when their field is deleted.

@philbarbato or @aaronbushnell, in your database's fieldlabels table, are there any labels with fieldIds that represent nonexistent fields?

[aaronbushnell]

Mine all seem to be accounted for!

Oddly enough the value for $event->newValue ended up being NULL when I inspected the error further. This line: https://github.com/spicywebau/craft-fieldlabels/blob/master/src/Service.php

Even more strange was there was one time where a save on a Neo field did work and didn’t throw this error.

Is it possible there’s some kind of race condition happening that large Neo setups are more susceptible to?

[ttempleton]

@aaronbushnell I think something like that was happening. I was never able to reproduce the error, but I fixed a couple of bugs I found with Neo and Field Labels along the way, which I hope will fix this error too. Basically there was a lot of field layout and field label deletion/recreation going on, more details below:

• When saving a Neo field, block type field layouts were being deleted before being recreated; the field layout deletion caused the associated Field Labels data to be deleted, before Neo's Field Labels integration code recreated them. This should now be fixed in Neo 2.7.24.
• Field Labels' field layout save event listener was running for Neo field layouts when it shouldn't have been. Field Labels looks for any label data under the fieldlabels POST data, but it's under neo[fieldlabels] for Neo field layouts. Field Labels then deletes any existing labels it didn't find in the POST data, which, in the Neo case, is all of them. This had no effect before the Neo field layout issue was fixed because the labels had already been deleted, but it did happen afterwards, so that was fixed in Field Labels 1.2.3.

Please let me know if the error is gone after updating!

[aaronbushnell]

Thanks a ton, @ttempleton! I know this stuff is almost impossible to diagnose so really appreciate you taking a stab here.

When we update I’ll let you know if we continue to encounter errors here!