-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LPS-132150 Fix error registering GraphQLDTOContributors because Facet GraphQLObjectType was not registered at that moment #1061
Conversation
… GraphQLObjectType was not registered The problem was caused by a race condition, because types coming from annotations are loaded asynchronously and when the type was requested by the GraphQLDTODefinition to be used as part of the Page definition, it was not available yet. To solve it I check if the type is available and if not, register it manually
…the Facet GraphQL annotations are processed. So change the approach removing the GraphQL annotations and registering the type at the beginning to be available for the graphql-annotations library and for the GraphQLDTOContributor registry
CI is automatically triggering the following test suites:
|
✔️ ci:test:sf - 1 out of 1 jobs passed in 3 minutesClick here for more details.Base Branch:Branch Name: master Sender Branch:Branch Name: LPS-132150 1 Successful Jobs:For more details click here. |
Jenkins Build:test-portal-source-format#5881 Jenkins Report:jenkins-report.html Jenkins Suite:sf Pull Request:liferay-frontend#1061 Testray Routine:EE Pull Request Testray Build:[master] ci:test:sf - javierdearcos > liferay-frontend - PR#1061 - 2021-05-13[23:06:34] Testray Importer:publish-testray-report#1011 |
Jenkins Build:test-portal-acceptance-pullrequest(master)#4790 Jenkins Report:jenkins-report.html Jenkins Suite:relevant Pull Request:liferay-frontend#1061 Testray Routine:EE Pull Request Testray Build:[master] ci:test:relevant - javierdearcos > liferay-frontend - PR#1061 - 2021-05-13[23:40:50] Testray Importer:publish-testray-report#765 |
Seems there is a missing baseline in the Failures in common with acceptance upstream results at 6e25ad1. Adding it |
Are you sure that's the case? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code is Ok. But I'm worried about the bug... can you double check if 1) you can reproduce it several times (I can't) 2) check if the annotations are really processed asynchronously. Thanks!
@@ -1237,6 +1256,11 @@ private Servlet _createServlet() throws Exception { | |||
Map<Class<?>, Set<Class<?>>> classesMap = | |||
processingElementsContainer.getExtensionsTypeRegistry(); | |||
|
|||
processingElementsContainer.setTypeRegistry( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why here? looks like more of a field related thing that should be before _collectObjectFields
I've tried to reproduce it all afternoon without success 😞 I'm pretty sure that the other day the classes were registered in an asynchronous way because as it executes the register... methods, the registered classes increase by hundreds (when there weren't so many registered) and the Facet class wasn't present, although it should be there just after the collect... methods. Maybe I was wrong the other day and it is better to close the bug until it happens again if it does |
I've checked the code internally and I don't see where it could be asynchronous... the error makes sense if there were no ServletData registered but having APIs in the server it does not makes sense. Closing for now, if it happens again, we'll reopen. |
Ok, I'll close the bug as no longer reproducible too |
The bug was caused by a race condition because types coming from annotations are loaded asynchronously and when the type was requested by the GraphQLDTODefinition to be used as part of the Page definition, it was not available yet. To solve it I try to check if the type is available and if not, register it manually.
This solution causes a conflict when the Facet class GraphQL annotations were processed and try to register the type again, so to avoid this conflict I choose to remove the annotations and always register the Facet type at the beginning to be available for GraphQL annotations processor and for the GraphQLDTOContributor registry.
I think it could be a good approach as we mentioned several times that we wanted to remove the GraphQL annotations lib.
I left both commits so you can check the process but we can squash them before sending the PR