InvalidArgumentException: Field uuid is unknown. in Drupal\Core\Entity\ContentEntityBase->getTranslatedField()

At minimum, this needs tests.

I know that UUIDs are not strictly required, but that was mostly intended for config entities AFAIK… because if content entities don't have UUIDs, they cannot be synced, so they cannot take advantage of automatic syncing and the Workflow initiative for example.

Demoting to Normal, precisely because it's extremely rare to have content entities that don't have UUIDs.

@Wim Leers I'll write the tests.

@arshadcn++

So looking at this again. I think the tests in #2 and #4 combined with the tests we wrote in #2843752: EntityResource: Provide comprehensive test coverage for Item entity should cover this (I saw the same issue when writing the tests for Item entity).

What do you think @Wim Leers?

Sorry, lost track of this issue! So much activity in the REST issue queue that this already was on the second issue page for all API-first core modules :)

I think you're right! #2843752: EntityResource: Provide comprehensive test coverage for Item entity already updated EntityResourceTestBase to support entity types without UUIDs. So we already have test coverage that proves REST works for entity types without UUIDs. This issue then should be concerned only with was originally reported: the HAL normalization of a content entity that references another content entity and that referenced content entity does not have a UUID.

But let's confirm this by uploading the patch in #4 without the fix: that should fail.

In the mean time, here's a review already:

1. +++ b/core/modules/hal/tests/src/Functional/EntityResource/EntityTest/EntityTestHalJsonRelatedTest.php
   @@ -0,0 +1,89 @@
   +    // Reload entity so that it has the new field.
   +    $this->entity = $this->entityStorage->loadUnchanged($this->entity->id());
   +
   +    // 'Entity Test without label' is also missing a UUID.
   +    // @see https://www.drupal.org/node/2835576
   +    $entity_test_no_label = EntityTestNoLabel::create([
   +      'name' => 'Baby Llama',
   +      'type' => 'entity_test_no_label',
   +    ]);
   +    $entity_test_no_label->save();
   +
   +    // Set a default value on the field.
   +    $this->entity->set($field_name, [
   +      'target_id' => $entity_test_no_label->id(),
   +    ]);
   +
   +    $this->entity->save();
   

   Let's move all of this to ::createEntity(), that will be much clearer.

   s/also//

   Then the "Set a default value on the field." stuff can be done in a far less confusing way.

2. +++ b/core/modules/hal/tests/src/Functional/EntityResource/EntityTest/EntityTestHalJsonRelatedTest.php
   @@ -0,0 +1,89 @@
   +      'required' => FALSE,
   

   And then this can become required instead of optional.

3. +++ b/core/modules/hal/tests/src/Functional/EntityResource/EntityTest/EntityTestHalJsonRelatedTest.php
   @@ -0,0 +1,89 @@
   +    $normalized['_embedded'][$this->baseUrl . '/rest/relation/entity_test/entity_test/field_entity_test_no_label'] = [
   +      [
   +        '_links' => [
   +          'self' => [
   +            'href' => '',
   +          ],
   +          'type' => [
   +            'href' => $this->baseUrl . '/rest/type/entity_test_no_label/entity_test_no_label',
   +          ],
   +        ],
   +        'lang' => 'en',
   +      ],
   +    ];
   

   What's key here is that uuid is missing. That's what this issue is changing. But… devil's advocate… then how are you supposed to fetch this referenced entity? The whole point is that referenced entities are "embedded" automatically, but the embedding is limited to just the UUID field. But if there's no UUID field… then how are you supposed to find the referenced entity?

   Should this then fall back to embedding the ID field?

   This is why it's so hugely problematic to have the HAL normalization require UUIDs, and then some entity types not having UUIDs at all!

But let's confirm this by uploading the patch in #4 without the fix: that should fail.

Done.

(Had to rebase, but git did that all automatically for me :))

Now back to NW for the remarks in #16.

This came up as a daily triage target

Here's a re-roll of the test only-patch.

The actual patch doesn't apply anymore because the code there is different, and I suspect the current code-path doesn't contain this bug.

If this passes, we can close as works as designed.

#2871591: Allow ComplexData in TypedData to specify computed properties that should be exposed in normalization and other contexts was where this was changed

PHPCS

More linting

Ok, so this fails, but differently

The old fail was Field uuid is unknown

The new fail is just that the expected value differs.

I still think this now works as designed by way of the array_intersect_key added in #2871591: Allow ComplexData in TypedData to specify computed properties that should be exposed in normalization and other contexts

@Wim Leers or @shadcn could you confirm?

The hal module has moved out of Drupal Core and into a Contrib Module.
Moving this issue to the Contrib Module queue.

Let's try that again...

Closing as a duplicate of #2871591: Allow ComplexData in TypedData to specify computed properties that should be exposed in normalization and other contexts