Fixed issues for Atlas are addressed in Cloudera Runtime 7.3.2, its
service packs and cumulative hotfixes.
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
