Overview

When working with the Aurora GraphQL API to query users and messages objects, you may encounter errors or unexpected behavior that differs from the legacy LiQL/REST API. Most of these issues fall into two categories: permission gaps on the API-calling account (which surface as DataFetchingException errors rather than clear "access denied" messages) and schema differences where fields available in LiQL do not have a direct GraphQL equivalent.

This article covers the most common issues, their root causes, and actionable workarounds.

In This Article

• Symptoms
• User Roles Query Returns DataFetchingException
• No last_visit_time Field in GraphQL
• Identifying Root Messages vs. Replies
• Users Query Only Returns FULLY_REGISTERED Users
• memberReport Query Returns Empty Results
• Additional Information
• FAQ

Symptoms

• Querying User.roles returns a DataFetchingException
• No last_visit_time field available in the GraphQL schema (unlike the legacy LiQL API)
• Unable to distinguish root messages (thread starters) from replies
• The users query only returns users with FULLY_REGISTERED status
• The memberReport query returns an empty result set

User Roles Query Returns DataFetchingException

Problem

Including roles in a users query produces an error like:

{
  "message": "Exception while fetching data (/users/edges[0]/node/roles)",
  "extensions": { "classification": "DataFetchingException" }
}

Cause

The API-calling account does not have permission to view role information. The roles resolver in Aurora requires the caller to hold role-management permissions.

Resolution

1. Confirm the issue is permissions-related by running a minimal query (id + roles) using an Admin-authenticated token. If it succeeds as Admin but fails with your current token, the root cause is a permissions gap.
2. In the Admin console, update the role assigned to the API-calling account and grant the required role-viewing permission. For background on how Aurora permissions are organized, see About Aurora roles and permissions.
3. Re-run the query with the updated account to verify the error is resolved.

Note: Granting role-management permissions will expand what that account can access, so review the scope carefully before making changes.

No last_visit_time Field in GraphQL

Problem

The LiQL API exposed a last_visit_time field for users, but there is no direct equivalent in the Aurora GraphQL schema.

Workaround A: Use User Metrics to Identify Inactive Users

The users query returns a metrics object with activity counters. You can identify users who registered but never connected by checking for zero values:

query UsersActivity($first: Int!, $after: String) {
  users(first: $first, after: $after) {
    edges {
      node {
        id
        uid
        login
        email
        registrationData {
          registrationTime
          status
        }
        metrics {
          logins
          minutesOnline
          messagesRead
          pageViews
        }
      }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

Filter on your side for users where logins == 0 (and optionally minutesOnline == 0, messagesRead == 0, pageViews == 0) to isolate "never connected" accounts.

Workaround B: Derive Last Visit from Bulk Data API

If you specifically need an actual last visit timestamp and the schema does not expose one, you can derive it from event data (page views / visits) via the Analytics/Bulk Data tooling. See Bulk Data API (v 3.0) for details. This requires aggregating events per user and is more involved than the metrics approach.

Discovering Fields in Your Schema

Use the schema search in the GraphQL Documentation Explorer to look for fields by keyword (e.g., last, visit, login). If a field is not returned, it is not exposed in your current schema version. See Using our GraphQL Documentation for instructions.

Identifying Root Messages vs. Replies

Problem

When querying messages, there is no obvious field that indicates whether a message is the original thread-starting post or a reply.

Resolution

Use MessageConstraints.depth to filter by message depth:

• depth: { eq: 0 } — returns only root messages (thread starters)
• depth: { gt: 0 } — returns only replies

Example query filtering for root messages only:

query RootMessages($first: Int!) {
  messages(
    first: $first,
    constraints: { depth: { eq: 0 } }
  ) {
    edges {
      node {
        id
        subject
        body
        postTime
        author {
          uid
          login
        }
      }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

For more examples, refer to the official Postman Collection.

Users Query Only Returns FULLY_REGISTERED Users

Problem

The users query only returns users with registrationData.status = FULLY_REGISTERED, even though partially registered users exist on the instance.

Explanation

In Aurora, partial registrations are typically registrations that were abandoned before the platform assigned a unique user ID. Because no User entity was created in the community directory, there is no record for the GraphQL users query to return.

The users query will only return actual User records that exist in the community directory — users who completed registration far enough for the system to assign a user ID.

memberReport Query Returns Empty Results

Problem

Running a memberReport query with startTime and endTime constraints returns an empty edges array.

Possible Causes

1. Permissions: The calling account may lack permissions required to access reporting data. Try the same query with an Admin-authenticated token.
2. Timestamp format: Ensure startTime and endTime use the format expected by your schema. Consult the schema documentation for the memberReport type to confirm the correct format (ISO 8601 strings vs. Unix timestamps).
3. Empty date range: Verify that the date range actually contains member activity data.

Additional Information

• When migrating from the LiQL API to GraphQL, not all fields have a 1:1 mapping. Use the GraphQL Documentation Explorer to search for equivalent fields in your schema. See Using our GraphQL Documentation.
• Permission-related errors in GraphQL typically surface as DataFetchingException rather than a clear "access denied" message. When you encounter this error, always test with an Admin token first to rule out permissions.
• For general guidance on forming GraphQL calls, see Forming calls with GraphQL in Aurora.

FAQ

Q1: Do I need to update every user's role to fix the roles query error?
A1: No. You only need to update the role of the API-calling account (the account whose token is used to authenticate GraphQL requests). Once that account has role-viewing permission, it can query roles for all users.

Q2: Can I get real-time "last seen" timestamps for users via GraphQL?
A2: Not directly. The metrics object provides cumulative activity counters (logins, minutes online, etc.) but not a specific timestamp. For timestamp-level data, use the Bulk Data API to extract event-level visit data and derive the last visit time.

Q3: How do I check which fields are available in my instance's GraphQL schema?
A3: Open the GraphQL Documentation Explorer on your instance (typically at /t5/s/api/2.1/graphql with the documentation UI) and use the built-in search to look for field names or keywords. See Using our GraphQL Documentation for step-by-step instructions.