[sergo] Sergo Report: HTTP Context Chain + Vestigial init() - 2026-04-06

[github-actions[bot]]

Executive Summary

Today's Sergo run combined an extension of the HTTP context propagation analysis (cached from the 2026-04-05 sentinel-extension run) with a new exploration of vestigial init() functions in pkg/workflow. The HTTP analysis grew from 2 known locations to 4 confirmed locations where HTTP requests are issued without a parent context.Context, preventing cancellation by the CLI's command lifecycle. The new exploration found 3 no-op init() functions that do nothing but log a message — dead code left from a prior refactor that removed embedded scripts.

The codebase continues to show consistent patterns: HTTP utility functions (deps check, registry search, download helpers) were all authored without context parameters, making them resistant to cooperative cancellation. Similarly, the pkg/workflow package has an inconsistency between files that load embedded JSON eagerly in init() (domains, permissions, toolsets) and files that load lazily via sync.Once (action_pins, schema_validation, docker_validation). Three tasks are proposed to address these findings.

---

🛠️ Serena Tools Update

Tools Snapshot

• Total Tools Available: 22
• New Tools Since Last Run: None
• Removed Tools: None
• Modified Tools: None

Tool Capabilities Used Today

• activate_project — project initialization
• list_dir — codebase structure exploration
• search_for_pattern (via bash grep) — HTTP call site detection, init() scanning
• find_symbol / get_symbols_overview — function signature and context verification

---

📊 Strategy Selection

Cached Reuse Component (50%)

Previous Strategy Adapted: sentinel-extension-and-context-http (2026-04-05, score 8/10)

• Why Reused: The 2026-04-05 run identified mcp_registry.go and deps_security.go as using http.NewRequest without context. The run scored 8/10 and the notes flagged that the analysis was incomplete — "sentinel-extension" was the primary finding and HTTP context was a secondary note. Worth extending.
• Modifications: Widened the search to client.Get() calls (not just http.NewRequest), and traced the full call chain from CLI command entry points down to the HTTP calls to confirm no context is available anywhere in the chain.

New Exploration Component (50%)

Novel Approach: Vestigial init() function audit

• Hypothesis: After the embedded-scripts refactor (confirmed by "embedded scripts removed" comments throughout js.go), some init() functions may have been left in place with only a log call as their body.
• Tools Employed: grep for ^func init() across pkg/, then reading each body
• Target Areas: pkg/workflow/*.go — 7 init() functions found and audited

Combined Strategy Rationale

The HTTP-context and init()-audit themes are orthogonal but both focused on startup efficiency and operational correctness: one prevents silent HTTP request leaks on command cancellation, the other removes startup log noise and reveals an inconsistent initialization pattern. Together they give good breadth across the CLI and workflow packages.

---

🔍 Analysis Execution

Codebase Context

• Total Go Files (non-test): 660
• Packages Analyzed: pkg/cli (HTTP pattern scan), pkg/workflow (init() audit)
• Focus Areas: HTTP call sites, init() functions, sync.Once usage

Findings Summary

• Total Issues Found: 3 compound findings (7 individual file locations)
• High: 1 (4 HTTP call sites without context)
• Medium: 2 (3 vestigial inits + init/sync.Once inconsistency)
• Low: 0

---

📋 Detailed Findings

High Priority: HTTP Requests Without Context Propagation

Four functions in pkg/cli issue HTTP requests using http.NewRequest or client.Get without a context.Context parameter. None of their callers pass a context either — the missing context propagates all the way from the CLI command handler.

File	Line	Function	Method
pkg/cli/mcp_registry.go	56	createRegistryRequest	http.NewRequest(method, url, nil)
pkg/cli/deps_security.go	138	querySecurityAdvisories	http.NewRequest(http.MethodGet, url, nil)
pkg/cli/deps_outdated.go	162	getLatestVersion	client.Get(url)
pkg/cli/agent_download.go	49	downloadAgentFileFromGitHub	client.Get(rawURL)

The callers — SearchServers, CheckSecurityAdvisories, CheckOutdatedDependencies, and downloadAgentFileFromGitHub — also have no ctx context.Context parameter. If the user presses Ctrl-C during a deps check or mcp add, the HTTP request will continue until the server responds or the client-level Timeout fires (typically 5–30 seconds). The request cannot be cancelled cooperatively.

Note: mcp_inspect_mcp_scripts_server.go:52 uses client.Get inside a polling health-check loop with its own deadline mechanism — this is acceptable and excluded from the task.

Medium Priority: Vestigial No-Op init() Functions

Three init() functions in pkg/workflow contain only a single log.Print call and perform no initialization work:

// pkg/workflow/js.go:14
func init() {
    jsLog.Print("Script registration completed (embedded scripts removed)")
}

// pkg/workflow/scripts.go:20
func init() {
    scriptsLog.Print("Script registration completed (embedded scripts removed)")
}

// pkg/workflow/expression_patterns.go:67
func init() {
    expressionPatternsLog.Print("Initializing expression pattern regex compilation")
}

The js.go and scripts.go inits are clear remnants of a refactor that removed embedded scripts — the log message itself says "embedded scripts removed". The actual regexp.MustCompile calls in expression_patterns.go happen in package-level var declarations; the init() only logs that the compilation is "initializing."

These three init() functions add entries to the startup log without doing meaningful work, which makes debugging startup behaviour harder (logs appear to show initialization happening, but nothing is actually being initialized).

Medium Priority: Inconsistent Embedded Data Loading Strategy

Within pkg/workflow, two conflicting patterns exist for loading embedded data:

Eager (init() at program start):

• domains.go:121 — parses ecosystemDomains JSON
• permissions_toolset_data.go:39 — parses githubToolsetsPermissionsJSON
• github_tool_to_toolset.go:20 — parses githubToolToToolsetJSON
• runtime_definitions.go:164 — builds commandToRuntime / actionRepoToRuntime maps

Lazy (sync.Once on first use):

• action_pins.go:54 — lazy-loads and caches actionPinsJSON
• schema_validation.go:56 — lazy-compiles JSON schema
• docker_validation.go:58 — lazy-checks Docker daemon availability
• agentic_engine.go:391 — lazy-initializes engine registry

Commands like gh-aw version, gh-aw help, or gh-aw compile (without domain-restricted features) still pay the startup cost of parsing domains/permissions/toolsets JSON, even when those packages are never used. The inconsistency also makes it harder for new contributors to know which pattern to follow when adding new embedded data.

---

✅ Improvement Tasks Generated

Task 1: Propagate context.Context Through HTTP Utility Functions

Issue Type: Code Navigation / API Correctness

Problem:
Four functions in pkg/cli issue HTTP requests without a context, preventing cooperative cancellation when the user interrupts a command (Ctrl-C) or when a parent deadline fires.

Locations:

• pkg/cli/mcp_registry.go:55-56 — createRegistryRequest(method, url string) and its caller SearchServers
• pkg/cli/deps_security.go:133-138 — querySecurityAdvisories(depVersions, verbose) and its caller CheckSecurityAdvisories
• pkg/cli/deps_outdated.go:155-162 — getLatestVersion(modulePath, currentVersion, verbose) and its caller CheckOutdatedDependencies
• pkg/cli/agent_download.go:21-49 — downloadAgentFileFromGitHub(verbose)

Impact:

• Severity: High
• Affected Files: 4 (+ callers in deps_report.go, mcp_add.go, mcp_registry_list.go)
• Risk: HTTP requests silently outlive command cancellation; user sees "stuck" CLI

Recommendation: Add ctx context.Context as the first parameter to each function and use http.NewRequestWithContext / http.MethodGet with context:

// Before
func (c *MCPRegistryClient) createRegistryRequest(method, url string) (*http.Request, error) {
    req, err := http.NewRequest(method, url, nil)

// After
func (c *MCPRegistryClient) createRegistryRequest(ctx context.Context, method, url string) (*http.Request, error) {
    req, err := http.NewRequestWithContext(ctx, method, url, nil)

// Before (deps_outdated.go)
func getLatestVersion(modulePath, currentVersion string, verbose bool) (string, time.Duration, error) {
    client := &http.Client{Timeout: 5 * time.Second}
    resp, err := client.Get(url)

// After
func getLatestVersion(ctx context.Context, modulePath, currentVersion string, verbose bool) (string, time.Duration, error) {
    client := &http.Client{Timeout: 5 * time.Second}
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    resp, err := client.Do(req)

Thread context from the cobra command's RunE function (which receives cmd.Context()) through the call chain to each HTTP site.

Validation:

• Confirm cmd.Context() is available at each command entry point
• Run existing tests after refactor
• Verify that Ctrl-C during gh-aw deps cancels the HTTP request

Estimated Effort: Medium

---

Task 2: Remove Vestigial No-Op init() Functions

Issue Type: Dead Code Removal

Problem:
Three init() functions in pkg/workflow do nothing except emit a log message. Two are explicit remnants of a refactor that removed embedded scripts; one logs that regex compilation is "initializing" when the actual compilation occurs in var declarations (not inside init()).

Locations:

• pkg/workflow/js.go:14-16
• pkg/workflow/scripts.go:20-22
• pkg/workflow/expression_patterns.go:67-69

Impact:

• Severity: Medium
• Affected Files: 3
• Risk: Misleading startup logs imply work is happening that isn't; vestigial code increases reader confusion

Recommendation: Delete all three init() functions. No callers depend on their side effects (confirmed by search — no test or production code references the log messages). If the log-level information is valuable, it belongs in a comment, not a runtime log statement.

// Delete entirely from js.go:
func init() {
    jsLog.Print("Script registration completed (embedded scripts removed)")
}

// Delete entirely from scripts.go:
func init() {
    scriptsLog.Print("Script registration completed (embedded scripts removed)")
}

// Delete entirely from expression_patterns.go:
func init() {
    expressionPatternsLog.Print("Initializing expression pattern regex compilation")
}

Validation:

• go build ./... succeeds
• Startup log no longer contains the three removed messages
• No test asserts on the log messages

Estimated Effort: Small

---

Task 3: Standardize Embedded Data Loading to Lazy sync.Once Pattern

Issue Type: Inconsistent Pattern / Startup Performance

Problem:
pkg/workflow mixes two incompatible initialization strategies for embedded data. Three files use eager init() (blocking at process start for every CLI invocation), while four others use lazy sync.Once (loaded only when first needed). Commands that never use domains, permissions, or toolsets still parse all their JSON on startup.

Locations (eager, to be converted):

• pkg/workflow/domains.go:121 — ecosystemDomains from embedded JSON
• pkg/workflow/permissions_toolset_data.go:39 — toolsetPermissionsMap from embedded JSON
• pkg/workflow/github_tool_to_toolset.go:20 — GitHubToolToToolsetMap from embedded JSON

Locations (lazy, existing model to follow):

• pkg/workflow/action_pins.go:54 — actionPinsOnce sync.Once + getActionPins() accessor

Impact:

• Severity: Medium
• Affected Files: 3 eagerly-loading files + all their callers (accessors)
• Risk: Eager loading adds 3 JSON parse operations to every gh-aw invocation; inconsistency confuses contributors about the correct pattern

Recommendation: Convert the three eager loaders to follow the action_pins.go model:

// Before (domains.go)
func init() {
    if err := json.Unmarshal(ecosystemDomainsJSON, &ecosystemDomains); err != nil {
        panic(...)
    }
}

// After
var (
    ecosystemDomainsOnce sync.Once
    ecosystemDomainsData map[string][]string
)

func getEcosystemDomains() map[string][]string {
    ecosystemDomainsOnce.Do(func() {
        if err := json.Unmarshal(ecosystemDomainsJSON, &ecosystemDomainsData); err != nil {
            panic(fmt.Sprintf("failed to load ecosystem domains from JSON: %v", err))
        }
    })
    return ecosystemDomainsData
}

Update all call sites that currently reference ecosystemDomains directly to call getEcosystemDomains(). Apply the same pattern to toolsetPermissionsMap and GitHubToolToToolsetMap.

Validation:

• All existing unit tests pass (no behavioral change, only initialization timing)
• Verify that gh-aw version startup log no longer shows domain/permissions/toolset loading messages
• Confirm that commands that use these features still work correctly

Estimated Effort: Medium

---

📈 Success Metrics

This Run

• Findings Generated: 3 compound findings (7 file locations)
• Tasks Created: 3
• Files Analyzed: ~660 Go files (pkg/cli + pkg/workflow deep-scan)
• Success Score: 8/10

Reasoning for Score

• Findings Quality (3/4): All three findings are actionable with clear code examples. The HTTP finding is High severity. Deducting 1 because no Critical-severity issues found.
• Coverage (2/3): Scanned all HTTP call sites in pkg/cli and all init() functions in pkg/workflow. Did not scan pkg/parser or pkg/agentdrain deeply today.
• Task Generation (3/3): Three well-scoped tasks with before/after code examples and clear validation steps.

---

📊 Historical Context

Strategy Performance (last 10 runs)

Date	Strategy	Score
2026-03-29	error-patterns-first-run	7
2026-03-30	multi-return-struct-refactoring	8
2026-03-30	close-error-propagation-and-context-depth	8
2026-03-31	mutex-safety-and-compile-time-checks	8
2026-04-01	regex-duplication-and-goroutine-context	9
2026-04-02	errors-new-anti-pattern-and-interface-assertions	8
2026-04-03	errorf-anti-pattern-revisit-and-map-set-standardization	7
2026-04-04	sentinel-error-standardization	8
2026-04-05	sentinel-extension-and-context-http	8
2026-04-06	http-context-chain-and-vestigial-inits	8

Cumulative Statistics

• Total Runs: 10
• Total Findings: 39
• Total Tasks Generated: 30
• Average Success Score: 7.9/10
• Most Successful Strategy: regex-duplication-and-goroutine-context (9/10)

---

🎯 Recommendations

Immediate Actions

1. [High] Context propagation through HTTP chain — Add ctx context.Context to createRegistryRequest, querySecurityAdvisories, getLatestVersion, downloadAgentFileFromGitHub and use http.NewRequestWithContext
2. [Medium] Remove 3 vestigial init() functions — Delete no-op inits from js.go, scripts.go, expression_patterns.go (small, safe, quick)
3. [Medium] Standardize embedded data to lazy sync.Once — Convert domains.go, permissions_toolset_data.go, github_tool_to_toolset.go to follow action_pins.go pattern

Long-term Improvements

The codebase has now had 10 consecutive days of static analysis. Observed patterns suggest a linter rule for http.NewRequest (flagging calls without context) and a custom vet check for init() functions with no side effects would catch these automatically. Consider adding staticcheck or revive to the CI pipeline with rules covering these patterns.

---

🔄 Next Run Preview

Suggested Focus Areas

• pkg/parser: Not deeply analyzed yet — likely has HTTP calls, error patterns, or context issues
• pkg/agentdrain: Small package (coordinator, miner) — worth a full symbol audit
• Goroutine lifecycle: The mcp_inspect_inspector.go goroutines (process monitoring) have no recovery — check if panics in serverCmd.Wait() paths could crash the inspector

Strategy Evolution

Consider a "caller chain tracing" strategy next: pick 3-5 exported functions, trace every caller up to the CLI entry point, and verify that context, cancellation, and error propagation are complete end-to-end. This would catch more systemic issues than per-file pattern matching.

---

References:

• §24049441738

Generated by Sergo - Serena Go Expert · ● 370.5K · ◷

• expires on Apr 7, 2026, 8:31 PM UTC

[github-actions[bot]]

This discussion has been marked as outdated by Sergo - Serena Go Expert.

A newer discussion is available at Discussion #25151.