github-actions[bot] commented on code in PR #65924:
URL: https://github.com/apache/doris/pull/65924#discussion_r3664498864


##########
docker/thirdparties/run-thirdparties-docker.sh:
##########
@@ -1644,7 +1644,8 @@ start_polaris() {
     register_stack_metadata "polaris" "${POLARIS_DIR}/docker-compose.yaml" ""
     compose_cmd "${POLARIS_DIR}/docker-compose.yaml" "" down --remove-orphans
     if [[ "${STOP}" -ne 1 ]]; then
-        compose_cmd "${POLARIS_DIR}/docker-compose.yaml" "" up -d --wait 
--remove-orphans
+        compose_cmd "${POLARIS_DIR}/docker-compose.yaml" "" up -d --wait 
--remove-orphans polaris
+        compose_cmd "${POLARIS_DIR}/docker-compose.yaml" "" run --rm --no-deps 
polaris-init

Review Comment:
   The parallel launcher records the background `start_polaris` shell PID, but 
this new foreground Compose process is its child. On a sibling startup failure, 
`kill_running_jobs` signals only the recorded shell; same-shape and 
exact-Compose probes left the child/one-off running after that shell exited. 
Default cleanup does not rescue it: `register_stack_metadata` also runs inside 
the background shell, so its array writes never reach the parent and 
`cleanup_started_stacks` skips Polaris. Initialization can therefore continue 
after the launcher returns failure. Please make the stack metadata 
parent-visible and terminate/wait for the full component process tree (or 
perform equivalent local signal/container cleanup), with a sibling-failure test 
while `polaris-init` is delayed.



##########
docker/thirdparties/docker-compose/polaris/init-catalog.sh:
##########
@@ -19,25 +19,84 @@ set -eu
 
 HOST=${POLARIS_HOST:-polaris-s3}
 PORT=${POLARIS_PORT:-8181}
+ADMIN_PORT=${POLARIS_ADMIN_PORT:-8182}
 USER=${POLARIS_BOOTSTRAP_USER:-root}
 PASS=${POLARIS_BOOTSTRAP_PASSWORD:-secret123}
 CATALOG=${POLARIS_CATALOG_NAME:-minio}
 BASE_LOCATION=${CATALOG_BASE_LOCATION:-s3://warehouse/wh/}
 
-echo "[polaris-init] Waiting for Polaris health check at 
http://$HOST:$PORT/q/health ..."
-for i in $(seq 1 120); do
-  if curl -sSf "http://$HOST:8182/q/health"; >/dev/null; then
+CURL_CONNECT_TIMEOUT_SECONDS=${POLARIS_INIT_CONNECT_TIMEOUT_SECONDS:-5}
+CURL_REQUEST_TIMEOUT_SECONDS=${POLARIS_INIT_REQUEST_TIMEOUT_SECONDS:-15}
+CURL_RETRY_COUNT=${POLARIS_INIT_RETRY_COUNT:-3}
+CURL_RETRY_DELAY_SECONDS=${POLARIS_INIT_RETRY_DELAY_SECONDS:-2}
+CURL_RETRY_MAX_TIME_SECONDS=${POLARIS_INIT_RETRY_MAX_TIME_SECONDS:-45}
+HEALTH_CHECK_ATTEMPTS=${POLARIS_INIT_HEALTH_CHECK_ATTEMPTS:-60}
+HEALTH_CHECK_INTERVAL_SECONDS=${POLARIS_INIT_HEALTH_CHECK_INTERVAL_SECONDS:-2}
+HEALTH_CHECK_REQUEST_TIMEOUT_SECONDS=${POLARIS_INIT_HEALTH_CHECK_REQUEST_TIMEOUT_SECONDS:-2}
+TOKEN_RESPONSE_FILE=/tmp/polaris-token.json
+
+# Keep every network operation bounded when an endpoint accepts a connection 
but never responds.
+trap 'rc=$?; if [ "$rc" -ne 0 ]; then echo "[polaris-init] ERROR: 
Initialization failed with exit code $rc." >&2; fi' 0
+
+require_positive_integer() {
+  name=$1
+  value=$2
+  case "$value" in
+    ''|*[!0-9]*)
+      ;;
+    *)
+      if [ "$value" -gt 0 ] 2>/dev/null; then
+        return
+      fi
+      ;;
+  esac
+  echo "[polaris-init] ERROR: $name must be a positive integer, got '$value'." 
>&2
+  exit 1
+}
+
+require_positive_integer POLARIS_INIT_REQUEST_TIMEOUT_SECONDS 
"$CURL_REQUEST_TIMEOUT_SECONDS"
+require_positive_integer POLARIS_INIT_HEALTH_CHECK_REQUEST_TIMEOUT_SECONDS 
"$HEALTH_CHECK_REQUEST_TIMEOUT_SECONDS"
+
+curl_with_retry() {
+  curl -sS \
+    --connect-timeout "$CURL_CONNECT_TIMEOUT_SECONDS" \
+    --max-time "$CURL_REQUEST_TIMEOUT_SECONDS" \
+    --retry "$CURL_RETRY_COUNT" \
+    --retry-delay "$CURL_RETRY_DELAY_SECONDS" \

Review Comment:
   `--retry-max-time` does not cap an already scheduled `--retry-delay`. With 
the pinned curl image, an immediate refusal using `--retry-delay 10 
--retry-max-time 1` was still sleeping after three seconds. Therefore 
`POLARIS_INIT_RETRY_DELAY_SECONDS=3600` and 
`POLARIS_INIT_RETRY_MAX_TIME_SECONDS=1` can still block every API call for an 
hour, defeating the advertised total retry bound. This is distinct from the 
existing BusyBox `sleep inf` thread because it is curl's finite internal retry 
delay. Please validate/cap the delay against the total budget (or enforce an 
explicit remaining-time loop) and add an exact-image delay-greater-than-max 
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]

Reply via email to