[Optimizely App] variation container allows incorrect variant type to be selected on first render

[LucasAmos]

Describe the bug
Given that an optimizely experiment has been linked to the contentful environment and 2 or more reference fields have been enabled on a content type. The first time that a new variation container entry is rendered on the screen any enabled content type can be selected from the "Content type" dropdown menu and added to the variation container. The next time that the entry is rendered only the correct content type can be selected.

To Reproduce
Steps to reproduce the behavior:

1. Install the optimizely app
2. Select 2 or more reference fields for a given content type
3. Add a new variation container to an entry
4. Select an optimizely experiment
5. For a variation click "Link an existing entry"
6. All content types will be visible
7. Select an invalid content type
8. The content type is added to the variation container
9. Re-render the variation container entry (e.g. refresh the page)
10. Only entries of the valid content type can now be selected despite an invalid content type entry having been added to the variation container

Expected behavior
Only entries of the correct content type can be added to the variation container via the "Content type" dropdown menu

Screenshots

Desktop (please complete the following information):

• OS: MacOS 13.4
• Browser Chrome
• Version 114.0.5735.106 (Official Build) (arm64)

Additional context
Add any other context about the problem here.

[LucasAmos]

I have identified the cause of the issue.

The API request space.getEntries({ links_to_entry: ids.entry, skip: 0, limit: 1000 }) sometimes returns an empty items array.

I have reproduced the error programatically and this bug manifests because the contentful API is eventually consistent. Adding a delay between linking the VariationContainer to the HomePage and fetching the entries that link to the HomePage mitigates the bug.

[whitelisab]

Hi @LucasAmos! Thank you for raising this issue. As communicated through our support process, we have captured this issue in our backlog and will prioritize it as soon as possible.

[whitelisab]

Just another quick update @LucasAmos. I am going to close this issue and we will continue to communicate updates to you about this bug through our internal support process. Thank you!

[juancarlosjr97]

Any update on this ticket? As this has been closed makes following it up is practically impossible.

[whitelisab]

@juancarlosjr97 Thanks for reaching out! This ticket has not been prioritized, but I will provide an update when we are working on it.

[juancarlosjr97]

@whitelisab... As @LucasAmos mentioned, the issue is the line

apps/apps/optimizely/src/EditorPage/index.js

Line 86 in ccd11a6

space.getEntries({ links_to_entry: ids.entry, skip: 0, limit: 1000 }),

that does not return the expected response but instead an empty array.

The reason, we think, is happening is because when the entry is created, it opens immediately the drawer and does the fetch of the L86, but as Contentful has just created the entry, the relationship does not exist yet, and if the patch of the parent entry with the newly created entry happens before the fetch data of L86 the array returns correct data, but if it happens after, it returns an empty array as the linked relationship does not exist yet.

Long story short, it requires an await for however long contentful takes to save an empty when a change happens on the UI and does the path.

[juancarlosjr97]

I have raised an MR to fix the bug - #4621 @whitelisab.

Please, if you could review it and merge it as we need this fix.