imbajin opened a new pull request, #366: URL: https://github.com/apache/hugegraph-computer/pull/366
Vermeer could not load graphs when PD required a deployment secret or Server required authentication for Schema reads. PD requests now resolve a protected password file through `VERMEER_PD_PASSWORD_FILE` / `pd_password_file`. Worker Schema reads separately resolve `VERMEER_HUGEGRAPH_CREDENTIALS_FILE` / `hugegraph_credentials_file`, without persisting deployment credentials in task parameters. Explicit invalid files fail closed; unconfigured deployments retain legacy behavior. Storage initialization errors now propagate before scans start, release initialization waiters before reporting to Master, and leave failed graphs safe to unload and retry. A blocked status RPC cannot prevent local receivers from leaving initialization. The barrier is held before publishing a task, receivers inspect its published initialization result, and vertex frames register before waiting. Initialization retains its original barrier pointer so cancellation cleanup cannot cause a second panic after recovery. A small authenticated `GET /api/v1/workers/availability` reports one readiness boolean for the credential's space allocations/common pool. It accepts no caller-selected space, requires no admin token and allocates no resources. Readiness follows explicit allocation precedence and requires every registered member of a candidate group to be Ready. Graph-specific candidates use exact keys from the authenticated space's actual graph names, without inferring ownership by prefixes. Worker connection publication shares the readiness lock and follows session construction. Both availability and scheduler admission also require the current Worker instance's three live task streams. Reverse gRPC readiness during hello is insufficient; canceled streams immediately disable readiness, cleanup preserves replacements, and missing initial dispatch streams return errors. Validation: targeted common, initialization/Schema, receiver and scoped-readiness regressions pass with `-race`; the dev build passes. Local PD gRPC + HTTP Basic Schema fixtures verify credential scope. A separate Schema observer loaded a fresh 1001-vertex graph on the retained real stack, with 1000 + 1 distinct results and real Chromium pagination. Independent cross reviews checked these changes. The cleanup regression fails against the previous source with a nil WaitGroup panic and passes with the fix. A real hello regression holds the ordinary memory-limit RPC: on 554daab it falsely advertises readiness and admits dispatch before streams exist; the new checked-in regression fails there and passes with the repair under -race. On 090bf27, a fresh retained-stack run established all real task streams, reloaded the source graph and returned six finite PageRank values. Existing structure Save/Load fixtures fail with an empty DataDir on both original and modified source, so a full str ucture-suite pass is not claimed. CI runs the affected regressions and loads its Buildx dry-run image before metadata checks. PD currently uses plaintext gRPC; the trusted-network requirement is documented and its TLS thread remains open for coordinated PD/client support. Hubble adapter, reproducible helpers and browser evidence: https://github.com/hugegraph/hugegraph-toolchain/pull/84. --- ## Upstream submission notes Source community PR: https://github.com/hugegraph/hugegraph-computer/pull/19. This upstream PR reuses the same source repository and branch. Validation statements above are reports from the source task; they were not independently rerun during upstream submission. At submission preflight, source-head hosted checks: 7 success. Upstream exact-head CI and current review feedback require separate confirmation; opening this PR does not establish merge or release readiness. -- 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]
