What would cause the UI to return no data on Users & Groups page? (i.e. not even the current root User itself - "datahub") I see that the page uses a Graphql query to find Users under the covers, but returns no data:

query listUsers($input: ListUsersInput!) {
  listUsers(input: $input) {
    start
    count
    total
    users {
      urn
      username
      isNativeUser
      info {
        active
        displayName
        title
        firstName
        lastName
        fullName
        email
        __typename
      }
      editableProperties {
        displayName
        pictureLink
        teams
        title
        skills
        __typename
      }
      status
      roles: relationships(
        input: {types: ["IsMemberOfRole"], direction: OUTGOING, start: 0}
      ) {
        start
        count
        total
        relationships {
          entity {
            ... on DataHubRole {
              urn
              type
              name
              relationships(input: {types: ["IsMemberOfRole"], direction: INCOMING}) {
                start
                count
                total
                __typename
              }
              __typename
            }
            __typename
          }
          __typename
        }
        __typename
      }
      __typename
    }
    __typename
  }
}

---> result:

{
  "data": {
    "listUsers": {
      "start": 0,
      "count": 25,
      "total": 0,
      "users": [],
      "__typename": "ListUsersResult"
    }
  },
  "extensions": {}
}

Is this query attempting to get the User list from the DataHub database? ..or if not, what is it querying? Could database access be affecting the returned result? Thanks, Pete

Hi @famous-quill-82626 Could you please copy the logs from container and attached here ? Steps for accessing logs are available at https://datahubproject.io/docs/how/extract-container-logs/#step-2-find-the-log-files/

It's possible that the search index is not up to date. (or is in the process of reindexing). Note that with the latest releaase the

datahub-upgrade

container will perform a required reindexing which can take some time to complete. During this time, you may not see your entities as expected!

Contents of gms.log (from GMS pod --> path: /tmp/datahub/logs/gms): Seeing lots of auth failed errors. e.g.

01:24:12 [ThreadPoolTaskExecutor-1] WARN  o.apache.kafka.clients.NetworkClient - [Consumer clientId=consumer-mce-consumer-job-client-1, groupId=mce-consumer-job-client] Error while fetching metadata with correlation id 2 : {dh_integrate_MetadataChangeEvent_v1=TOPIC_AUTHORIZATION_FAILED}
01:24:12 [ThreadPoolTaskExecutor-1] ERROR org.apache.kafka.clients.Metadata - [Consumer clientId=consumer-mce-consumer-job-client-1, groupId=mce-consumer-job-client] Topic authorization failed for topics [dh_integrate_MetadataChangeEvent_v1]
01:24:12 [ThreadPoolTaskExecutor-1] INFO  org.apache.kafka.clients.Metadata - [Consumer clientId=consumer-mce-consumer-job-client-1, groupId=mce-consumer-job-client] Cluster ID: lkc-9kk0zv
01:24:12 [ThreadPoolTaskExecutor-1] ERROR o.s.k.l.KafkaMessageListenerContainer$ListenerConsumer - Authorization Exception and no authorizationExceptionRetryInterval set
org.apache.kafka.common.errors.TopicAuthorizationException: Not authorized to access topics: [dh_integrate_MetadataChangeEvent_v1]
01:24:12 [ThreadPoolTaskExecutor-1] ERROR o.s.k.l.KafkaMessageListenerContainer$ListenerConsumer - Fatal consumer exception; stopping container
01:24:12 [main] INFO  o.a.k.c.consumer.ConsumerConfig - ConsumerConfig values: 
	allow.auto.create.topics = true
	<http://auto.commit.interval.ms|auto.commit.interval.ms> = 10000
	auto.offset.reset = latest
	bootstrap.servers = [pkc-3wp5o.ap-southeast-2.aws.confluent.cloud:9092]
	check.crcs = true
	client.dns.lookup = use_all_dns_ips
	client.id = 
	client.rack = 
	<http://connections.max.idle.ms|connections.max.idle.ms> = 540000
	<http://default.api.timeout.ms|default.api.timeout.ms> = 60000
	enable.auto.commit = true
	exclude.internal.topics = true
	fetch.max.bytes = 52428800
	<http://fetch.max.wait.ms|fetch.max.wait.ms> = 500
	fetch.min.bytes = 1
	group.id = generic-platform-event-job-client
	group.instance.id = null
	<http://heartbeat.interval.ms|heartbeat.interval.ms> = 3000
	interceptor.classes = []
	internal.leave.group.on.close = true
	isolation.level = read_uncommitted
	key.deserializer = class org.apache.kafka.common.serialization.StringDeserializer
	max.partition.fetch.bytes = 1048576
	<http://max.poll.interval.ms|max.poll.interval.ms> = 300000
	max.poll.records = 500
	<http://metadata.max.age.ms|metadata.max.age.ms> = 300000
	metric.reporters = []
	metrics.num.samples = 2
	metrics.recording.level = INFO
	<http://metrics.sample.window.ms|metrics.sample.window.ms> = 30000
	partition.assignment.strategy = [class org.apache.kafka.clients.consumer.RangeAssignor]
	receive.buffer.bytes = 65536
	<http://reconnect.backoff.max.ms|reconnect.backoff.max.ms> = 1000
	<http://reconnect.backoff.ms|reconnect.backoff.ms> = 50
	<http://request.timeout.ms|request.timeout.ms> = 30000
	<http://retry.backoff.ms|retry.backoff.ms> = 100
	sasl.client.callback.handler.class = null
	sasl.jaas.config = [hidden]
	sasl.kerberos.kinit.cmd = /usr/bin/kinit
	sasl.kerberos.min.time.before.relogin = 60000
	sasl.kerberos.service.name = null
	sasl.kerberos.ticket.renew.jitter = 0.05
	sasl.kerberos.ticket.renew.window.factor = 0.8
	sasl.login.callback.handler.class = null
	sasl.login.class = null
	sasl.login.refresh.buffer.seconds = 300
	sasl.login.refresh.min.period.seconds = 60
	sasl.login.refresh.window.factor = 0.8
	sasl.login.refresh.window.jitter = 0.05
	sasl.mechanism = PLAIN
	security.protocol = SASL_SSL
	security.providers = null
	send.buffer.bytes = 131072
	<http://session.timeout.ms|session.timeout.ms> = 10000
	ssl.cipher.suites = null
	ssl.enabled.protocols = [TLSv1.2, TLSv1.1, TLSv1]
	ssl.endpoint.identification.algorithm = https
	ssl.key.password = null
	ssl.keymanager.algorithm = SunX509
	ssl.keystore.location = null
	ssl.keystore.password = null
	ssl.keystore.type = JKS
	ssl.protocol = TLS
	ssl.provider = null
	ssl.secure.random.implementation = null
	ssl.trustmanager.algorithm = PKIX
	ssl.truststore.location = null
	ssl.truststore.password = null
	ssl.truststore.type = JKS
	value.deserializer = class io.confluent.kafka.serializers.KafkaAvroDeserializer

Hey @famous-quill-82626 Was this resolved after waiting for search index to update? I’m seeing the same thing (for groups) only. Confirmed that the groups exist in mysql

Hi @famous-quill-82626 This is definitely an inconsistency between your MySQL and the elasticsearch index which should reflect these things. A couple things to try: 1. Restart datahub-gms pod to ensure the local search and list caches are cleared 2. You can always try to restore indices if you continue to see this issue. This will restore the elastic indexes based on the contents of MySQL -> https://datahubproject.io/docs/how/restore-indices

This was definitely due to a Search issue - we have AWS OpenSearch and once I made the appropriate configuration settings to cause the search indexing to happen, we were able to see new entities. If I edited existing entities (to force them to get re-indexed I assume), they also appeared on the UI. Cheers --> Issue Resolved.