[Bug] Standalone Docker image stuck at "Waiting for partition assignment..." for 120s

[imbajin]

Bug Type

server status (startup / runtime exception)

Before submit

• I have confirmed and searched that there are no similar problems in the historical issues and documents

Environment

• Server Version: 1.7.0 (latest master)
• Backend: RocksDB (standalone, default)
• OS: macOS / Linux (Docker)
• Image: hugegraph/hugegraph:latest built from hugegraph-server/Dockerfile

Expected & Actual behavior

Expected: The standalone image built from hugegraph-server/Dockerfile should start successfully and be ready to use immediately after docker run.

Actual: The server starts up (HTTP listener bound to 8080), but then keeps printing Waiting for partition assignment... for ~120 seconds before timing out:

INFO: Started listener bound to [0.0.0.0:8080]
INFO: [HttpServer] Started.
Started [pid 1017]
Waiting for partition assignment...
Waiting for partition assignment...
Waiting for partition assignment...
Waiting for partition assignment...
Waiting for partition assignment...

Root Cause:

PR #2952 (0154c064) refactored docker-compose and added an unconditional call to wait-partition.sh in docker-entrypoint.sh:

# Line 84-90 in docker-entrypoint.sh
STORE_REST="${STORE_REST:-store:8520}"
export STORE_REST
./bin/start-hugegraph.sh -j "${JAVA_OPTS:-}" -t 120
./bin/wait-partition.sh || log "WARN: partitions not assigned yet"

wait-partition.sh polls http://store:8520 looking for "partitionCount":[1-9] — this is only meaningful in distributed hstore mode. In standalone rocksdb mode, there is no Store service, so it loops for 120 seconds before timing out.

In contrast, wait-storage.sh correctly guards against this: it skips the PD wait entirely when no hstore-related environment variables are set.

Vertex/Edge example

N/A — this is a Docker startup issue, not a data issue.

Schema [VertexLabel, EdgeLabel, IndexLabel]

N/A

[imbajin]

@bitflicker64 Already add a patch for it

[bitflicker64]

@bitflicker64 Already add a patch for it

@imbajin Thanks for the quick catch and patch! I'll add a reference to #3000 in the PR #2952 description.