Skip to content

fix(capability): declare associative arrays before service registry port fallback - #5865

Closed
vaibhavsrv wants to merge 1 commit into
Osmantic:public-betafrom
vaibhavsrv:fix/capability-unbound-ports
Closed

vaibhavsrv wants to merge 1 commit into
Osmantic:public-betafrom
vaibhavsrv:fix/capability-unbound-ports

Conversation

@vaibhavsrv

Copy link
Copy Markdown
Contributor

Why this matters

In ods/scripts/build-capability-profile.sh, when the capability profiler runs without an active lib/service-registry.sh file, the script attempts to evaluate _LLM_PORT="${SERVICE_PORTS[llama-server]:-11434}". Because set -u is enabled and SERVICE_PORTS has not yet been declared as an associative array via declare -A, bash interprets the index llama-server as an arithmetic expression referencing an undeclared variable llama. This triggers a fatal llama: unbound variable error and crashes hardware capability profiling during standalone or isolated CLI executions.

This patch declares SERVICE_PORTS and SERVICE_HEALTH as associative arrays prior to inspecting or sourcing the service registry, ensuring that string keys evaluate safely under set -u even when the registry library is not loaded.

Validation

  • Repro baseline: Executed build-capability-profile.sh in an isolated directory without lib/service-registry.sh; confirmed bash exited with code 1 and llama: unbound variable.
  • Post-fix: Verified test_capability_unbound_ports.py passes with exit code 0; capability profiling completes successfully, generating capabilities.json with fallback port 11434.
  • Capability suites: 1 passed. New-test Ruff, ShellCheck, and diff checks pass; new regressions wired into Linux CI.

Overlap check

Risk / AI disclosure

AI-assisted investigation, implementation and CLI regressions. This strengthens variable declarations in shell profiling utilities under strict mode, not runtime service admission. Independent human review and platform/runtime qualification remain gates. No running configuration, deployment or upstream merge changed.

Follow-up integration evidence

Composed with #5861 at 2a24f49 without conflicts. Production and test diffs passed together; capability and hardware classification checks remain intact.
Backlog composition was local-only (production/test diffs, excluding workflow/Makefile wiring); it is not an upstream merge or independent human approval. Declared live-review gates remain open.

@Lightheartdevs

Copy link
Copy Markdown
Collaborator

Thanks for this contribution. public-beta was promoted into main on 2026-09-24 and no longer receives changes, so we're closing pull requests that target it. This isn't a judgment on the change itself. If it's still needed, please rebase onto main and open a focused PR. See #7253 for details and the contribution policy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants