Fixed Issues in Atlas

Cloudera Runtime 7.3.2.100 CHF 1

CDPD-103625: Remote streaming should be disabled as this feature has known security implications.

7.3.2.100

Remote streaming in the Apache Solr configuration for Apache Atlas is now disabled by default because it has known security implications. The enableRemoteStreaming="true" attribute has been removed from the <requestParsers> element in solrconfig.xml.

CDPD-91624: Perform Degradation: Atlas Replication is 3-4x Slower in 7.3.2 vs. 7.1.9

7.3.2.100

A performance degradation was observed in the asynchronous table replication process after upgrading from version 7.1.9 to 7.3.2, where the average time to replicate a single table increased significantly. This issue is resolved. The asynchronous import path is optimized by caching intermediate states, consolidating import and bookkeeping operations to reduce graph transactions by more than 50%, and updating the processed entities structure to improve lookup efficiency. These changes significantly improve asynchronous import throughput without altering replication logic.

CDPD-94458: searchRelatedEntities - Add pagination, optional sorting, fix approximate count while fetching relationships of an entity

7.3.2.100

When an entity had a very large relationship graph, the searchRelatedEntities API (GET /v2/search/relationship) could return all related entities in one response, which caused slow load times or an unresponsive Atlas user interface. The API now supports pagination, and the Atlas user interface loads the Relationships tab on the entity detail page in pages instead of retrieving the entire graph at once. The API always applied default alphabetical sorting by name even when you did not request sorting, which added overhead for large result sets and slowed deep pagination. The optional disableDefaultSorting query parameter (set to true) skips default name sorting for faster natural graph traversal order; default alphabetical ordering is unchanged when you omit the parameter.

When an attribute can reference multiple entity types (for example, hive_db.tables containing hive_table and hbase_table), the API previously returned entities of only one type and omitted other valid related entities; for example, it could not return complete results when a Hive database contained both Hive and Apache Iceberg tables. searchRelatedEntities now traverses all applicable relationship types and returns every related entity across mixed entity types. Approximate relationship counts could be incorrect when you excluded deleted entities, because the count logic filtered by relationship (edge) status instead of related entity (vertex) status; counting now evaluates entity status and returns accurate totals, including relationships that span multiple entity types.

Apache Jira: ATLAS-5194, ATLAS-5241

Cloudera Runtime 7.3.2

Cloudera Runtime 7.3.2 resolves Atlas issues and incorporates fixes from the service packs and cumulative hotfixes from 7.3.1.100 through 7.3.1.700. For a comprehensive record of all fixes in Cloudera Runtime 7.3.1.x, see Fixed Issues.

CDPD-82058: UI displays current time instead of "NA" when server returns date fields as '0'

7.3.2

When the Atlas server returns date field values as 0 (zero) in API responses, the user interface incorrectly displays these fields as the current system time instead of showing "NA" (Not Available) to indicate that no valid date is present. This causes confusion when viewing entity details, audit logs, or other date-related information where timestamps are expected but not available. The fix modifies the UI utility functions in both the classic and React-based user interfaces to properly detect zero date values and display "NA" instead of converting them to the current time.

Apache JIRA: ATLAS-5015

CDPD-84505: Advanced Search not working properly in Atlas UI

7.3.2

When using the Advanced Search feature in the Atlas user interface, selecting a type definition (typeDef) and clicking the search button fails to return any results or fetch entities for the selected type. This issue affects the search result layout view in both the classic and React-based user interfaces. The broken functionality forces users to rely on Basic Search instead of the more powerful Advanced Search capabilities. The fix corrects the search result handling logic to properly process and display search results for type-based queries.

CDPD-87670: Atlas Glossary becomes unresponsive when page size is set to 50

7.3.2

When viewing a glossary item that has more than 25 associated entities and changing the page limit to 50 in the Glossary section, the Atlas user interface becomes unresponsive and displays an error alert with the message "expected type AtlasGlossaryCategory; found AtlasGlossaryTerm". This issue was caused by the UI calling an incorrect API endpoint. The fix corrects the API call to properly handle larger page sizes in the Glossary section.

Apache JIRA: ATLAS-5067

CDPD-82062: UI displays current time instead of "NA" when server returns date fields as '0'

7.3.2

The fix updates date handling utilities in both the classic and React-based Atlas user interfaces so that when API responses contain date field values as 0 (zero), the UI displays "NA" (Not Available) instead of converting them to the current system time.

Apache JIRA: ATLAS-5015

CDPD-89296: Basic search API fails to validate nested and grouped filter criteria

7.3.2

Previously, the /v2/search/basic API endpoint validated only top-level, non-grouped filter criteria. When entity or tag filters used grouped conditions (created with the Add Group Filter option in the Atlas UI), the API did not recursively validate nested FilterCriteria objects. This caused requests with composite or grouped filters to fail with a bad request error such as "Invalid operator specified for attribute: null". The fix adds recursive validation that correctly handles both grouped filter conditions (which require an AND/OR condition and contain nested criteria) and leaf-level filter criteria (which require a valid operator, a non-blank attribute name, and a non-blank attribute value, except when using IS_NULL or NOT_NULL operators). Requests that fail validation now return a descriptive error message.

Apache JIRA: ATLAS-5053

CDPD-81913: Auto-created Kafka topics are not audited to Atlas on ZooKeeper-based clusters

7.3.2

When a Kafka topic was automatically created (for example, following a produce attempt on a non-existent topic), Kafka set the error code to 3 (UNKNOWN_TOPIC_OR_PARTITION) in the MetadataResponse. The Atlas Kafka hook uses an entity selector that only processes audit events with a zero error code, causing topic auto-creation events to be silently dropped and not audited to Atlas. This issue only affected ZooKeeper-based Kafka clusters; KRaft-based clusters handle topic creation differently and were not affected. The fix updates the Atlas Kafka hook to recognize and correctly audit topic auto-creation events even when the MetadataResponse contains a non-zero error code.

OPSAPS-69156: Use '=' with add-opens/add-modules/add-exports

7.3.2

The JVM option syntax used by Atlas is normalized to use the equals format for module-related flags (for example, --add-opens=..., --add-exports=..., and --add-modules=...). This avoids failures in environments where JAVA_TOOL_OPTIONS does not correctly handle the space-separated variant and improves portability across JDK runtimes.

CDPD-80582: The Atlas client should retry on HTTP 500 errors

7.3.2

When the Atlas plugin attempted to bootstrap the Kafka or Schema Registry model and the Atlas server returned an HTTP 500 error (for example, error code ATLAS-500-00-005 with the message "Failed to get the lock; another type update might be in progress"), the client did not retry the request. This caused the Atlas plugin within Schema Registry to fail initialization permanently, resulting in subsequent errors such as "schema_metadata_info: Unknown/invalid typename". The fix updates the Atlas client retry logic to also retry requests that fail with HTTP 500 (Internal Server Error), in addition to the already-handled HTTP 503 (Service Unavailable) errors.

Apache JIRA: ATLAS-4571

CDPD-69213: Export/Import, Incremental Export: When entity exported has a tag propagated from entity which is deleted, tag is not propagated to it at target

7.3.2

When creating tables with multiple levels of depth, a tag applied to the first table was propagated along the lineage. After dropping the first table and exporting the entire lineage, child tables did not have the propagated tag after import on the target cluster. The root cause was a task ordering issue in the deferred actions flow: when deferred actions were enabled during import, the add-propagation task was created before the parent entity was deleted, but ran after the deletion, finding the edge between the parent entity and the classification in a deleted state and therefore not propagating the tag to child entities. The fix adds a check in the tag propagation logic to skip the edge-status validation when import is in progress and deferred actions are enabled, ensuring that tags are correctly propagated to child entities even when the source entity has been deleted.

Apache JIRA: ATLAS-5055

CDPD-68761: Atlas 'updateTime' parameter is not updated when term is added

7.3.2

When a glossary term was assigned to or removed from an entity, the entity's updateTime metadata field was not updated to reflect the modification. Clients or processes that relied on updateTime to detect entity changes would not recognize updates made through term assignment or removal. The fix calls the entity modification metadata update after each term assignment and dissociation operation in the glossary term processing logic, ensuring that updateTime correctly reflects the latest change.

Apache JIRA: ATLAS-4848

CDPD-67277: Improve efficiency in access request handling by optimizing classification retrieval

7.3.2

When processing bulk classification operations on large numbers of entities, the authorization layer retrieved full classification objects for each entity to perform access checks, even though only the classification names were required. This caused unnecessary graph traversals and redundant data loading, resulting in significantly increased processing time as the number of entities and classifications grew. The fix optimizes the access request handling by using classification names directly instead of iterating over full classification objects, and by replacing the heavier entity header retrieval call that fetched all classification objects with a lighter call during authorization checks. Performance testing with 260 entities showed processing time reductions of up to 50% depending on the number of classifications involved.

CDPD-79730: Provide liveness and readiness probes in Atlas

7.3.2

Atlas now provides two REST API endpoints to support container orchestration health checks. The liveness probe endpoint (GET /api/atlas/admin/liveness) returns HTTP 200 when the Atlas service state is ACTIVE or MIGRATING, and HTTP 500 when the service requires a restart. The readiness probe endpoint (GET /api/atlas/admin/readiness) returns HTTP 200 only when the Atlas service is ACTIVE and both the index store and the backend store are active, and HTTP 500 otherwise. These endpoints enable container orchestration platforms such as Kubernetes to correctly determine when to restart an Atlas pod and when to route traffic to it.

Apache JIRA: ATLAS-4826

CDPD-70221: Atlas incremental export takes too much time

7.3.2

When performing an incremental export of Hive database entities, Atlas traversed every connected entity in the graph and loaded the full entity object, including all extended information, for each one solely to check whether its modification timestamp fell within the export window. This resulted in data loading overhead equivalent to that of a full bootstrap export, regardless of how few entities had actually changed. The fix introduces an optimized code path for incremental exports of Hive database entities: Atlas now reads the modification timestamp directly from the graph vertex property and loads the full entity only when the timestamp qualifies, avoiding unnecessary data loading for entities that have not been modified since the last export.

Apache JIRA: ATLAS-4979

CDPD-89927: Option to customize name of the configuration filename

7.3.2

Atlas now supports a system property named atlas.properties to specify the configuration filename to load, instead of being limited to atlas-application.properties. This enables hooks and utilities to use custom property filenames (for example, -Datlas.properties=custom-atlas.properties).

Apache JIRA: ATLAS-5098