Bug Type (问题类型)

logic (逻辑设计问题)

Before submit

• 我已经确认现有的 Issues 与 FAQ 中没有相同 / 重复问题 (I have confirmed and searched that there are no similar problems in the historical issue and documents)

Environment (环境信息)

• Server Version: 1.0.0 (Apache Release Version)
• Backend: RocksDB x nodes, HDD or SSD
• OS: xx CPUs, xx G RAM, Ubuntu 2x.x / CentOS 7.x
• Data Size: xx vertices, xx edges

Expected & Actual behavior (期望与实际表现)

Follow-up from #2997 / #2740.

Code pointer:

Expected behavior

When Cassandra is temporarily unavailable or restarted, the Cassandra backend should handle transient connectivity failures consistently between synchronous and asynchronous write paths.

CassandraSessionPool.Session.commit() now uses executeWithRetry() and can retry transient failures such as NoHostAvailableException.

commitAsync() should either provide equivalent retry support for async writes, or explicitly define and document different reliability semantics.

Actual behavior

CassandraSessionPool.Session.commitAsync() bypasses executeWithRetry() and calls Datastax Session.executeAsync(...) directly.

During a Cassandra restart, async writes issued through commitAsync() can fail with transient driver errors such as NoHostAvailableException.

The failure is only surfaced through the Datastax ResultSetFuture / getUninterruptibly() flow. Callers that do not inspect these futures carefully may miss failed async writes.

This creates inconsistent behavior:

commit() -> executeWithRetry() -> transient retry support
commitAsync() -> executeAsync() -> no async retry support

Vertex/Edge example (问题点 / 边数据举例)

Schema [VertexLabel, EdgeLabel, IndexLabel] (元数据结构)