-
Notifications
You must be signed in to change notification settings - Fork 110
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
[Bug]: DataHub not working in test Env #836
Comments
Thank you for reporting this. |
Run in test env and try to execute any query. |
Unfortunately I couldn't reproduce, it would be helpful if you could provide more insights. |
what happens if you enable this for you:
|
I've just checked again, it doesn't do that for an out-of-the box setup. We added our own datahub provider that extends the graphql one. Basically allowing us to add custom configs and modify the query set. It only happens when you do that. If you are interested, I can give you access to the repo. It's private. |
not true, after further investigation, it also happens without my bundle when using a graphql config with documents enabled and framework.test enabled. this config fails for me: pimcore_data_hub:
configurations:
test:
general:
active: true
type: graphql
name: test
description: ''
group: ''
sqlObjectCondition: ''
modificationDate: 1708453670
path: null
createDate: 1708453186
schema:
queryEntities: { }
mutationEntities: { }
specialEntities:
document:
read: true
create: false
update: false
delete: false
document_folder:
read: false
create: false
update: false
delete: false
asset:
read: true
create: false
update: false
delete: false
asset_folder:
read: false
create: false
update: false
delete: false
asset_listing:
read: false
create: false
update: false
delete: false
object_folder:
read: false
create: false
update: false
delete: false
translation:
read: false
create: false
update: false
delete: false
translation_listing:
read: false
create: false
update: false
delete: false
coreshop_frontend:
read: true
create: false
update: false
delete: false
security:
method: datahub_apikey
apikey:
- f3025c050b6e7934c33a737a2ab5069d
skipPermissionCheck: false
disableIntrospection: false
workspaces:
asset: { }
document: { }
object:
-
read: true
cpath: /
create: false
update: false
delete: false
id: extModel1438-1
permissions:
user: { }
role: { }
|
@kingjia90 Its a test setup, so config might be messed up due to testing ;) I also don't know what is going on... But whatever it is, it should be fixed. It makes it quite uncomfortable to test with data-hub with these weird issues. |
Did that emerge recently, or has it always been that way? |
no idea |
I was just about to report this issue for We had this issue before, it's due to the fact the type map is kept around between (test) requests, but the type objects are created again and again, I'm not sure exactly why that is. We've workaround it by doing something like this private static ?InputObjectType $type = null;
public function getGraphQlMutationOperatorConfig($nodeDef, $class = null, $container = null, $params = []): array
{
return [
'arg' => ['type' => Type::listOf(self::$type ??= new InputObjectType([
// etc... Since the instance of the type is kept around somewhere and then the type map is checked for name and instance in We had this issue even with regular use, not just in tests, if the same operator was assigned multiple times. |
Hi!
I've yet to find out exactly why, but it only happens whenever I spread an object in the query. For example:
Or field collection:
However I do not have documents set for the query at all. It appears to be triggered at random, possibly when making changes to the Query Schema but I've had a hard time verifying that. This is a really bad failure for the stability of the API so I'm hoping it can be resolved. I've no confidence it will be stable and run in production at the moment 😬 |
It's not triggered at random, the cause of this is, as I've noted before, the same type is used twice (two different uses), but the type map has a reference only to the first one. For example, if you have a type called say
When The offending line: The workaround is to make all the Pimcore types singletons as I've shown in the previous comment, but the actual fix is to disallow creating the same type twice at all. |
@dkarlovi What I meant by "random" is that there are no apparent reason this error occurs in my instance. I am not using PHP to set this up, I'm using the Pimcore datahub GUI. But then the exact same query would start working later, without making any apparent changes to it. What is the defining factor that causes this to happen specifically for the internal document type of email then? |
Update:
Which produces the error:
The deploy clear caches for example, I can share what it does in more details if that would be relevant. I can get the error removed if I remove all my spread data in the query. So this one works (but I have to remove ALL spread data):
Once the error started to occur again this error pops up in the playground: middleware.js:98 Uncaught Error: {
"errors": [
{
"message": "Internal server error",
"locations": [
{
"line": 12,
"column": 5
}
],
"path": [
"__schema",
"types"
]
}
]
}
at Object.next (middleware.js:98:43578)
at b (middleware.js:98:5893)
at E (middleware.js:98:6399)
at e.value (middleware.js:98:6952)
at middleware.js:124:179565 and the schema is not possible to load. Expanding that tab merely keeps it "loading" infinitely. Now, if I disable introspection for my endpoint, I instead get this error: middleware.js:98 Uncaught Error: {
"errors": [
{
"message": "GraphQL introspection is not allowed, but the query contained __schema or __type",
"locations": [
{
"line": 2,
"column": 3
}
]
}
]
}
at Object.next (middleware.js:98:43578) Which is also interesting because afaik my query does not contain So far, things I've tested to see if I can get the error removed again:
EDIT: I can still get a result from the playground if I remove the spread objects even with the schema errors. |
Can anyone please at least help me with how I can circumvent this issue in the meantime? @kingjia90 I'm happy to patch whatever I need, I know my way around PHP, just not the vast Pimcore codebase or ecosystem as I just started my first project with it 😅 Right now I'm severely crippled by this error:
As it means I cannot spread any object in my graphQL, not even getting imageGallery or parent objects ids. Thank you in advance |
@jonathan-dejong Thank you for having a look and for the detailed info. Unfortunately, I was also stuck and i currently don't have any tips/suggestions on how to workaround it, besides to not using the TEST env. I will have a deeper look in what you have already researched and posted to see if i get some more clues on how it could be solved, but it may take some time. |
@kingjia90 Thanks, So just wondering if you can maybe help me in how I can ensure that test mode is definitely not turned on? 🙇 |
This issue is unrelated to the test env, even though it's more likely to get triggered in the test env. |
At least I figured out that we were setting |
Hi.. I'm facing the same problem and can't find a proper work around. I tested the app_env settings and yes.. it works if I change the value from test to dev.. Only problem here is that my dev config is different from the test config (links to settings, etc.). That's why I can't really use this approach. Are there any other options? I've noticed that the issue appears after I added specific fields to the GraphQL definition. Any help would be appreciated. |
Expected behavior
should wortk
Actual behavior
not working
Steps to reproduce
run it in test env and you see:
It comes down the following:
config_test.yaml
framework.test
to trueI didn't really quite understand why this service is instantiated twice and why it works when its inlined. here is the GraphQlService from inlined vs not:
Not Inlined:
Inlined
You can see that the EmailType get's instantiated twice, in both cases. But I did not understand why one works and the other doesn't. Anyhow: That service should always only get instantiated once anyway. So there is an issue with the service declaration somewhere.
The text was updated successfully, but these errors were encountered: