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