Skip to content
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

DomainEntitiesResolver class does not support values FacetFilterInput parameter #10102

Closed
skrydal opened this issue Mar 21, 2024 · 3 comments
Closed
Labels
bug Bug report stale

Comments

@skrydal
Copy link
Contributor

skrydal commented Mar 21, 2024

Describe the bug
Schema of GMS GraphQL indicates that domains object returned by listDomains query has a function entities which takes DomainEntitiesInput as input, which in turn contains variable filters which, according to the schema, allows for fields:

condition: FilterOperator
field: String!
negated: Boolean
value: String
values: [String!]

With an indication that value field is deprecated and values should be used instead. Unfortunately handling of values is not properly implemented - trying to issue query having input containing values instead of value field ends up with a server side exception.

To Reproduce
Issue GraphQL query:

query listDomains {
  listDomains(input: {start: 0, count: 1000}) {
    start
    count
    total
    domains {
      urn
      properties {
        name
      }
    dataProducts: entities(
      input: {start: 0, count: 0, filters: [{field: "_entityType", values: ["DATA_PRODUCT"]}]}
    ) {
      total
      __typename
    }
      __typename
    }
    __typename
  }
}

Instead of expected output, a list of server-side exceptions (code 500) is returned. Closer look at GMS logs indicates that (log comes from datahub version 0.12.0 so line numbers do not match but problem persists in current master):

Caused by: java.lang.NullPointerException: Cannot set field value of com.linkedin.metadata.query.filter.Criterion to null
	at com.linkedin.metadata.query.filter.Criterion.setValue(Criterion.java:304)
	at com.linkedin.datahub.graphql.resolvers.domain.DomainEntitiesResolver.lambda$get$0(DomainEntitiesResolver.java:77)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
	at com.linkedin.datahub.graphql.resolvers.domain.DomainEntitiesResolver.lambda$get$1(DomainEntitiesResolver.java:76)

Expected behavior
values field is used in the filter criterion. Additionally value field should be supported too as schema indicates it is supported but deprecated. As to what should happen if both of them are provided I am not sure.

Additional context
There is clear indication what stands behind this bug, the class implementation uses filter.getValue() and not getValues() at all:
https://github.com/datahub-project/datahub/blob/master/datahub-graphql-core/src/main/java/com/linkedin/datahub/graphql/resolvers/domain/DomainEntitiesResolver.java#L83

@skrydal skrydal added the bug Bug report label Mar 21, 2024
@sgomezvillamor
Copy link
Contributor

@jjoyce0510 Is this a known issue? any plan to fix soon?

While we could overcome this by using the deprecated value fiend until fixed, we access GMS GraphQL through a GraphQL Mesh component which has an issue preventing us using deprecated fields 😅 So the request on fixing in GMS

Copy link

This issue is stale because it has been open for 30 days with no activity. If you believe this is still an issue on the latest DataHub release please leave a comment with the version that you tested it with. If this is a question/discussion please head to https://slack.datahubproject.io. For feature requests please use https://feature-requests.datahubproject.io

@github-actions github-actions bot added the stale label Apr 22, 2024
Copy link

This issue was closed because it has been inactive for 30 days since being marked as stale.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Bug report stale
Projects
None yet
Development

No branches or pull requests

2 participants