Problem/Motivation

Since #2478507: Schema configs missing dependencies to property and processor providers, the processing form is broken. After adding at least one processor, adding an Activity Creator processor does not work. It breaks in ProcessorBase::getPropertyDefinitions() where $this->propertyDefinitions seems to be wrongly initialized by deserialization. Not sure why.

Proposed resolution

Remaining tasks

User interface changes

API changes

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Arla’s picture

Status: Active » Needs review
Issue tags: +Needs tests
FileSize
1.49 KB

Quick fix: remove the lazy loading

Arla’s picture

Issue tags: -Needs tests

Sorry, no tests needed. They already exist and are failing, but of course they are in #2430111: Re-add tests when CRM Core is on drupal.org, not committed. I say let's test this manually and commit it, then update the CRM tests separately.

mbovan’s picture

Status: Needs review » Needs work

I applied the patch attached to the #26 in #2476539: Extend contact matcher and contact creation to support user URIs and the patch 1 from this issue, but still having troubles to add 2 contact matcher processors and 1 activity creator (like in the tests). Contact matcher processors are added and then when I try to add activity creator (or to remove those 2) I get 400 Bad Request.

Arla’s picture

Assigned: Unassigned » Berdir
Priority: Normal » Major
FileSize
255.18 KB

Trying to debug this. Seems like a bug with serialization/unserialization, not sure exactly where or what. The screenshot shows the state at a breakpoint in __wakeup for a schema plugin, where the elements in $this->propertyDefinitions are incorrectly unserialized: The 'uid' property is a PropertyDefinition (correct), the 'uuid' property is a FieldItemDataDefinition (wrong) and the rest of the properties are just TRUE (wrong). The correct PropertyDefinition objects have instead ended up as an array in $this->propertyDefinitions['uid']->dataDefinition->itemDefinition->fieldDefinition.

This is a bit tricky to debug further, as the object in its serialized form is 80 KB of text (gist).

Hoping that @Berdir has got something to add.

Arla’s picture

Used ser-pretty to pretty-print the serialized object, got this: gist. Interesting part:

                  'uuid' =>
                  reference to 1248
                  'langcode' =>
                  reference to 1275
                  'preferred_langcode' =>
                  reference to 1299
                  ...

I guess that means references to already printed objects, but those numbers do not occur elsewhere so I cannot tell.

Edit: Also in the serialized-and-then-pretty-printed gist, the PropertyDefinition objects are inside uid->dataDefinition->itemDefinition->fieldDefinition.

Arla’s picture

Status: Needs work » Needs review
FileSize
1.93 KB

Took a break from trying to find the exact problem, and instead found another "quick fix" that doesn't solve but rather avoids it. The patch just removes the static caching of propertyDefinitions from SchemaBase.

Also tried to write a test for this, but I cannot make it fail without the fix :)

Arla’s picture

Actually I had to combine the two fixes to get this working well enough. That is, removing static caching of property definitions from two different classes. That kind of narrows it down a bit.

Arla’s picture

Let's commit this for now, to enable us to proceed with other issues, and turn this issue into restoring the removed caching.

  • Arla committed 7302f82 on 8.x-1.x
    Issue #2495039 by Arla: Adding processor broken (temporary quick fix)
    
Arla’s picture

Title: Adding processor broken » Restore and fix static caching of propertyDefinitions
Priority: Major » Normal
Status: Needs review » Needs work

Committed and pushed.

Changing title to reflect the new goal.