github-actions[bot] commented on code in PR #66083:
URL: https://github.com/apache/doris/pull/66083#discussion_r3664722976
##########
fe/fe-core/src/main/java/org/apache/doris/qe/ConnectContext.java:
##########
@@ -217,6 +217,10 @@ public enum ConnectType {
// cloud cluster name
protected volatile String cloudCluster = null;
+ // Stable compute group id for the current in-flight request. Unlike the
name,
+ // the id remains unchanged when the compute group is renamed.
+ protected String computeGroupId = null;
Review Comment:
[P1] Keep the stable ID synchronized with session state
`computeGroupId` lives outside `SessionVariable`, so existing session
mutations do not keep this pair synchronized. For example, after selecting
group A through the two-argument setter, `SET compute_group=B` updates
`SessionVariable.cloudCluster` reflectively while leaving ID A;
`COM_RESET_CONNECTION` likewise replaces the session variables without clearing
the ID. `createDummyLocation()` then prefers the stale nonempty ID and
bootstraps an empty auto-partition sink on A even though the current
session/planner group is B. Treat the name and ID as one correlated selection
across SET, reset, clone, and session-replacement paths, and cover A ->
reset/SET -> B.
##########
fe/fe-core/src/main/java/org/apache/doris/load/routineload/RoutineLoadJob.java:
##########
@@ -1060,10 +1060,10 @@ public TPipelineFragmentParams
plan(NereidsStreamLoadPlanner planner, TUniqueId
if (ConnectContext.get() == null) {
ConnectContext ctx = new ConnectContext();
ctx.setThreadLocalInfo();
- ctx.setCloudCluster(cloudCluster);
+ ctx.setCloudCluster(cloudCluster, cloudClusterId);
Review Comment:
[P1] Populate and schedule from the routine-load ID
`cloudClusterId` is never assigned anywhere in the routine-load package: all
constructors and `CloudRoutineLoadManager.addRoutineLoadJob()` retain only
`cloudCluster`. This changed call therefore passes `(oldName, null)` for new
Kafka/Kinesis jobs, and backend allocation still looks up the mutable name.
After a compute-group rename, allocation returns no BEs and pauses the job; if
the rename lands after allocation, replanning falls back to the old name and
the create-task path pauses it instead. Capture and persist the ID at job
creation, use it for both allocation and replanning, and cover legacy replay
plus rename interleavings.
##########
fe/fe-core/src/main/java/org/apache/doris/cloud/system/CloudSystemInfoService.java:
##########
@@ -1052,6 +1052,10 @@ public List<Backend> getBackendsByClusterName(final
String clusterName) {
}
public List<Backend> getBackendsByClusterId(final String clusterId) {
+ CloudComputeGroupMeta computeGroup = getComputeGroupById(clusterId);
+ if (computeGroup != null && !computeGroup.isVirtual()) {
Review Comment:
[P2] Preserve the controlled failure for a disappeared ID
A real group drop can remove the metadata while an in-flight context still
retains its nonempty ID. In that case `computeGroup` is null, this branch falls
through, the ID resolves through `""` to a null physical ID, and the final
`ConcurrentHashMap.getOrDefault(null, ...)` throws `NullPointerException`. The
old name-based sink path produced an empty list and the contextual `no
available BE` `UserException`. Handle a missing ID/group mapping here with an
empty snapshot or typed failure, and add an invalid-ID/drop test.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
