hashgraph / hashgraph/solo-weaver

refactor: audit direct config.Get() reads in workflow steps for BLL eligibility

Open
#1,092 0 comments 0 reactions 0 assignees View on GitHub
Improvement
Dominant language
Go
Stars
3
Forks
0
Avg merge
3d 5h
Merged PRs (30d)
47

Description

## Summary

Several workflow steps and commands read `config.Get()` directly for values that may benefit from the BLL effective-value resolution pattern:

- **Network firewall** (`step_network_firewall.go:63`) — reads `config.Get().Host`
- **Network setup** (`network_setup.go:85`) — reads `config.Get().Host.Disabled`
- **SoloOperator checks** (`cluster.go:81`, `step_health.go:135`) — reads `config.Get().SoloOperator.Enabled`
- **Host firewall CLI** (`host_firewall.go:149,519`) — reads `config.Get().Host`

## Problem

These reads bypass the layered resolution, meaning they cannot be overridden by CLI flags or reality checks. For simple boolean gates (like `SoloOperator.Enabled`), this is fine — they don't have a multi-source resolution problem. But host/network values that interact with deployed state could benefit from reality-aware resolution.

## Proposed solution

This is an **audit and triage** ticket. For each direct `config.Get()` read:

1. Determine if it has a multi-source resolution problem (can reality, state, or CLI flags legitimately override it?)
2. If yes — move it into the appropriate BLL resolver
3. If no — document why direct config read is intentional and leave it as-is

Expected outcome: most of these will stay as direct reads (they're simple gates), but the audit ensures nothing is missed.

## Scope

- [ ] Audit each `config.Get()` call site listed above
- [ ] Triage: BLL-eligible vs intentionally direct
- [ ] Move eligible fields into BLL resolution (if any)
- [ ] Document rationale for fields left as direct reads

Contributor guide

Open the contributing guide

Research direction

Start by reading the listed call sites in step_network_firewall.go, network_setup.go, cluster.go, step_health.go, and host_firewall.go, then compare them with existing BLL effective-value resolvers. Audit each read for reality, state, or CLI override needs. Done means every site is classified, eligible reads are moved, and intentional direct reads have documented rationale.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
cli, tooling
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.