This is for sure a bug that needs to be fixed. However, I think we need to approach it differently.

I think the problem actually has to do with the fact that we do not properly identify the type ofArticle orVideo and as a result, we fall back onto thejson type forDocument.

We're failing thisif statement which ensures that all the member types (Article andVideo) are object types.

The type data is coming fromhere and the definition for that ishere.

We identify the types of the schemahere and unfortunately,Article andVideo are determined to benull instead ofobject because we do not deference the schemas inside.

I think what we need to do is to makegetSchemaTargetGraphQLType() more robust by consideringoneOf/allOf and dereferencing member schemas.

In essence, I think we should move some of the logic from processing theoneOf/allOf intogetSchemaTargetGraphQLType().

Let me know if this all makes sense to you!

@Alan-Cha yeah that makes total sense. As I said, I somehow knew that my changes were probably just to naive and a bandaid and has some major flaws I just couldn't see by myself. I talked to my team an my PO, and it's a story in our current sprint now and I can dedicate actual work time to dive deeper into this problem (which helps a lot). Thanks so far, and I will get back to you as soon as I have something. Btw is there a chat or some plattform you use for this community? Something where interaction is more immediate? If not that's ok, just asking. Best regards

@ftatzky If you would like to take another look at this problem, that would be super cool! Otherwise, I will have to take a look at this in the upcoming weeks as I'm juggling some other tasks right now. I'm happy to answer whatever questions you have though!

I think it should be easy to medium difficulty, leaning more towards easy. I think you are on the right track. We should havegetSchemaTargetGraphQLType() returnunion. Checking fornull andobjecthere when we are trying to create aunion is confusing. We just need to follow move the existing logic for determining whether or not to create a union and put it intogetSchemaTargetGraphQLType().

Yes! We have aGitter chat room! Again, would be happy to answer any questions that you may have.

There is one consideration we should make.

Currently, the plan is to move the existing logic intogetSchemaTargetGraphQLType(), we should still consolidateallOf andoneOfhere, and basically check if thetargetGraphQLType (fromgetSchemaTargetGraphQLType()) isunionhere, and only if this is true, will we use theoneOf tocreate the union.

basically check if thetargetGraphQLType (fromgetSchemaTargetGraphQLType()) isunionhere

Actually on second thought, we should probably just utilize theswitch statement

My one concern is that we might want to useoneOf to do other things besides creating a union and this kind of logic flow may impede that.

An example of how we can useoneOf for other things is, given the following schema

{"type":"number","oneOf": [     {"multipleOf":5 },     {"multipleOf":3 }   ] }

We could create a new type that would actively check if it fits themultipleOf requirement.

However, for now, I think we only useoneOf to create unions. I'm just saying it would be nice to refactor in such a way that we can still useoneOf for other purposes without making the logic too complicated. For now, we don't necessarily need to do that.

Edit: Actually, I think everything will be fine if we just utilize the switch statement. Don't worry about what I said.

Let me know if this makes any sense! I might just be rambling 😅