[sergo] Sergo Report: Context-Propagation Revisit + Dead-Code Audit - 2026-03-13

[github-actions[bot]]

Date: 2026-03-13
Strategy: context-propagation-revisit-plus-dead-code-audit
Success Score: 7/10
Run ID: §23072627078

Executive Summary

Today's run (run 20) combined a revisit of the long-standing context-propagation/sleep audit (50% cached) with a novel dead-code sweep of date-time parsing utilities (50% new). The context-propagation component confirmed two previously reported unfixed issues: getLatestWorkflowRunWithRetry still uses bare time.Sleep without context cancellation, and dispatch.go's getRepoDefaultBranch still lacks a context.Context parameter. The dead-code audit uncovered a new issue in time_delta.go's normalizeDateTimeString: a smartFormats slice of 12 format strings containing ordinal suffixes that can never match their input, because ordinals were stripped two lines earlier.

Two previously reported issues were confirmed fixed since the last run: gateway_logs.go scanner buffer calls (runs 13–19) and mcp_inspect_mcp.go context propagation (run 8) are now correctly handled. The codebase continues to show improvement, though several long-standing issues remain open.

🛠️ Serena Tools Update

Tools Snapshot

• Total Tools Available: 40 (23 active, 17 inactive)
• New Tools Since Last Run: None
• Removed Tools: None
• Modified Tools: None — tool set stable since 2026-03-11

Tool Capabilities Used Today

• activate_project — activated gh-aw Go workspace
• list_dir — explored pkg/ package structure
• get_symbols_overview — overview of tool_graph.go, compile_stats.go, audit_report_analysis.go, log_aggregation.go
• find_referencing_symbols — traced call graph for generateExampleFromSchema, generateExampleJSONForPath
• search_for_pattern — pattern-matching for type assertions and scanner usage
• Bash grep/read — bulk pattern analysis across 581 Go files

📊 Strategy Selection

Cached Reuse Component (50%)

Previous Strategy Adapted: context-sleep-audit-plus-polling-infra (run 9, 2026-02-28, score 8)

• Original Success Score: 8/10
• Last Used: 2026-02-28 (13 days ago)
• Why Reused: Context cancellation in blocking calls is a persistent pattern in this codebase. Run 9 identified getLatestWorkflowRunWithRetry's uncancellable time.Sleep, and run 19 (yesterday) identified dispatch.go's getRepoDefaultBranch. Confirming these are still unfixed tracks technical debt accumulation.
• Modifications: Extended the sweep to include dispatch.go follow-up from run 19, and verified whether any newly modified files introduced new context-free HTTP/subprocess calls.

New Exploration Component (50%)

Novel Approach: Dead-code audit of string/time utility functions using mismatched ordinal format strings.

• Tools Employed: Bash grep, Read, mcp__serena__find_referencing_symbols
• Hypothesis: Utility functions that handle ordinal date strings (1st, 2nd, etc.) often have layered pre-processing that inadvertently renders downstream processing dead code.
• Target Areas: pkg/workflow/time_delta.go, pkg/parser/schema_suggestions.go

Combined Strategy Rationale

Context-propagation audits have consistently delivered HIGH-severity findings, making them reliable for the cached component. Pairing this with dead-code audits of string-manipulation utilities provides breadth coverage of a different class of bug (logical errors vs. resource management), while also scanning recently introduced utility code that hasn't been analyzed in previous runs.

🔍 Analysis Execution

Codebase Context

• Total Go Files: 581 (excluding tests)
• Packages Analyzed: pkg/cli, pkg/workflow, pkg/parser
• Focus Areas: run_workflow_tracking.go, dispatch.go, time_delta.go, expression_validation.go, secret_extraction.go, gateway_logs.go, mcp_inspect_mcp.go, tool_graph.go, compile_stats.go

Confirmed Fixed Issues

• ✅ gateway_logs.go lines 336 and 777: both missing scanner.Buffer(buf, maxScannerBufferSize) calls — now FIXED (all 4 scanner instances confirmed with Buffer call)
• ✅ mcp_inspect_mcp.go: context.Background() replaced with context.WithTimeout(context.Background(), 30*time.Second) — now FIXED

Findings Summary

• Total Issues Found: 3
• Critical: 0
• High: 1
• Medium: 2
• Low: 0

📋 Detailed Findings

High Priority Issues

[H1] getLatestWorkflowRunWithRetry: Uncancellable retry sleep — run_workflow_tracking.go:73

The function retries up to 6 times with exponential backoff (2s–10s intervals), but time.Sleep(delay) at line 73 cannot be interrupted. The caller has no way to propagate a context.Context down, so pressing Ctrl+C during the wait phase leaves the user blocked until the current sleep interval expires. The codebase already has PollWithSignalHandling in signal_aware_poll.go designed for exactly this use case.

// Current (run_workflow_tracking.go:73)
time.Sleep(delay)  // blocks Ctrl+C for up to 10 seconds

// Should use:
// PollWithSignalHandling(ctx, delay, ...)

This has been reported and unfixed since run 9 (2026-02-28).

Medium Priority Issues

[M1] normalizeDateTimeString: smartFormats are dead code — time_delta.go:271-283 (New finding)

normalizeDateTimeString strips ordinal suffixes from its input at line 244:

dateTimeStr = ordinalPattern.ReplaceAllString(dateTimeStr, "$1")
// "June 1st 2025" → "June 1 2025"
// "1st June 2025" → "1 June 2025"

Then at lines 271–283, a smartFormats slice is constructed and tried against the already de-ordinalized dateTimeStr:

smartFormats := []string{
    "January 2nd 2006",   // requires "nd" in input
    "2nd January 2006",   // requires "nd" in input
    "Jan 2nd 2006",
    "2nd Jan 2006",
    // ... 8 more ordinal-suffixed formats
}
for _, format := range smartFormats {
    if parsed, err := time.Parse(format, dateTimeStr); err == nil { // dateTimeStr has NO ordinals!

In Go's time.Parse, "January 2nd 2006" requires the literal text "nd" after the day digit. Since dateTimeStr was de-ordinalized two lines earlier, these formats will never match. The 12-format smartFormats slice is entirely dead code.

Additionally, the standard formats list (lines 192–238) already covers these patterns after ordinal removal (e.g., "2 January 2006" at line 222 matches "1 June 2025" after stripping "1st June 2025"). The smartFormats block is therefore both dead and redundant.

The error message at line 292 claims support for "1st June 2025" — this claim is true but succeeds via the standard formats, not smartFormats. A maintainer reading this code would incorrectly assume smartFormats provides ordinal parsing coverage.

[M2] regexp.MustCompile in function bodies and loops — expression_validation.go:288,400 + secret_extraction.go:50,56 (Unfixed since run 14)

Three functions compile fixed regular expressions on every invocation:

1. expression_validation.go:288 — orPattern := regexp.MustCompile(...) inside validateSingleExpression, which is called recursively (line 295 calls itself). Each recursive call recompiles.
2. expression_validation.go:400 — regexp.MustCompile(^\d+-\d+$) inside a for loop, recompiled on every iteration.
3. secret_extraction.go:50,56 — Two regexps compiled inside ExtractSecretsFromValue, called for every secret-containing expression.

All three should be package-level var declarations compiled once at startup.

Low Priority / Notes

time_delta.go smartFormats secondary inconsistency: Line 260–266 tries normalizedStr (double-space collapsed), but line 286 tries dateTimeStr (pre-normalization). Should use normalizedStr for consistency with the preceding block.

tool_graph.go:124 ambiguous separator: Transition keys use "->" as separator (fmt.Sprintf("%s->%s", from, to)), but strings.Split(key, "->") would produce len > 2 if tool names ever contain "->". In practice, tool names use underscores, so no current impact. LOW.

schema_suggestions.go:377 generateExampleFromSchema recursion depth: No depth limit unlike the sibling collectSchemaPropertyPaths (which has schemaTraversalMaxDepth = 15). In practice bounded by the internal schema depth. LOW.

Stable Unfixed Issues (tracked, not repeated):

• dispatch.go:93 — getRepoDefaultBranch no context (run 19)
• GetSupportedEngines/GetAllEngines/GetEngineByPrefix non-deterministic map iteration (run 2+)
• DependencyGraph no mutex on nodes/reverseImports (run 11)
• pr_command.go transferPR os.Chdir without CWD restore (run 16)
• deps_outdated.go:161 new http.Client per call in sequential loop (run 18)
• mcp_registry.go:95,112 io.ReadAll without size limit (run 17)
• deps_security.go pagination missing + io.ReadAll without limit (run 8)
• stringutil.Truncate byte-level slicing (run 18)
• git_helpers.go runGitWithSpinner no context (run 15)

✅ Improvement Tasks Generated

Task 1: Add context cancellation to getLatestWorkflowRunWithRetry

Issue Type: Context Propagation / Polling

Problem:
getLatestWorkflowRunWithRetry in run_workflow_tracking.go:73 uses time.Sleep(delay) for retry backoff. This call cannot be interrupted by context cancellation, meaning Ctrl+C during the wait phase leaves the user blocked for up to 10 seconds. The codebase has PollWithSignalHandling in signal_aware_poll.go designed for cancellable polling.

Location(s):

• pkg/cli/run_workflow_tracking.go:29 — function signature (no ctx context.Context parameter)
• pkg/cli/run_workflow_tracking.go:73 — time.Sleep(delay) call
• pkg/cli/run_workflow_execution.go — caller(s) of getLatestWorkflowRunWithRetry

Impact:

• Severity: High
• Affected Files: 2–3 (tracking + execution + callers)
• Risk: User experience degradation (up to 10s uninterruptible wait on Ctrl+C); consistent with PollWithSignalHandling pattern not being used where it should be

Recommendation:
Add ctx context.Context as the first parameter to getLatestWorkflowRunWithRetry. Replace time.Sleep(delay) with a context-aware sleep using select:

// Before
time.Sleep(delay)

// After
select {
case <-time.After(delay):
case <-ctx.Done():
    return nil, ctx.Err()
}

Or refactor to use PollWithSignalHandling if the retry logic aligns with its interface.

Validation:

• Run existing tests
• Verify Ctrl+C during retry wait exits promptly
• Check all callers pass appropriate context

Estimated Effort: Small

---

Task 2: Fix dead smartFormats in normalizeDateTimeString

Issue Type: Dead Code / Logic Bug

Problem:
normalizeDateTimeString in time_delta.go strips ordinal suffixes from its input at line 244, then at lines 271–284 constructs a smartFormats slice of 12 format strings that all contain ordinal suffixes ("2nd", "nd", etc.). Since the input no longer contains ordinals at that point, these format strings can never produce a successful parse. The block is dead code.

Location(s):

• pkg/workflow/time_delta.go:244 — ordinal stripping
• pkg/workflow/time_delta.go:271-290 — smartFormats block (dead code)

Impact:

• Severity: Medium
• Affected Files: 1
• Risk: Maintenance hazard — a developer removing line 244 (thinking smartFormats handles ordinals) would break ordinal date parsing. Comment at line 270 claims "Handle formats like 'June 1st 2025'" which is misleading since it's the standard formats that handle these, not smartFormats.

Recommendation:
Remove the smartFormats block entirely (lines 271–290). The standard formats slice already handles these patterns after ordinal removal (e.g., "2 January 2006" matches "1 June 2025" after stripping "1st June 2025"). Update the comment at line 269 to clarify that ordinal dates are handled by stripping (line 244) followed by standard formats.

// Before (lines 269-290, dead code):
// If none of the standard formats work, try some smart parsing
// Handle formats like "June 1st 2025", "1st June 2025", etc.
smartFormats := []string{
    "January 2nd 2006",
    ...
}
for _, format := range smartFormats {
    if parsed, err := time.Parse(format, dateTimeStr); err == nil {
        return parsed.UTC().Format("2006-01-02 15:04:05"), nil
    }
}

// After: Remove smartFormats block entirely.
// Add clarifying comment after line 266:
// Ordinal date strings (e.g. "1st June 2025") are handled by the
// ordinalPattern replacement at line 244, which converts them to
// standard numeric forms matched by the formats list above.

Validation:

• Run existing date-time parsing tests
• Verify "1st June 2025", "June 1st 2025", "2nd January 2026" all parse correctly via standard formats
• Add test cases explicitly covering ordinal input strings

Estimated Effort: Small

---

Task 3: Move function-body regexp.MustCompile to package-level variables

Issue Type: Performance / Code Quality

Problem:
Three functions compile fixed regular expressions on every invocation instead of declaring them as package-level variables:

1. validateSingleExpression (expression_validation.go:288): compiles orPattern on each call, AND the function is recursive — O(n) compilations per expression tree
2. extractRuntimeImportPaths loop (expression_validation.go:400): regexp.MustCompile inside a for loop — one compilation per loop iteration
3. ExtractSecretsFromValue (secret_extraction.go:50,56): two regexps compiled on each call to this per-expression utility

Location(s):

• pkg/workflow/expression_validation.go:288 — orPattern := regexp.MustCompile(...)
• pkg/workflow/expression_validation.go:400 — regexp.MustCompile(...) inside for loop
• pkg/workflow/secret_extraction.go:50 — exprPattern := regexp.MustCompile(...)
• pkg/workflow/secret_extraction.go:56 — secretPattern := regexp.MustCompile(...)

Impact:

• Severity: Medium
• Affected Files: 2
• Risk: Unnecessary CPU allocation on every compilation step; particularly wasteful for validateSingleExpression which is called recursively

Recommendation:
Move all four regexps to the package-level var block (which already exists in expression_validation.go at lines 64–80):

// Add to existing package-level var block in expression_validation.go:
var (
    // existing regexps ...
    orPatternRegex          = regexp.MustCompile(`^(.+?)\s*\|\|\s*(.+)$`)
    lineRangeRegex          = regexp.MustCompile(`^\d+-\d+$`)
)

// Add to package-level in secret_extraction.go:
var (
    exprPatternRegex   = regexp.MustCompile(`\$\{\{[^}]+\}\}`)
    secretPatternRegex = regexp.MustCompile(`secrets\.([A-Z_][A-Z0-9_]*)`)
)

Validation:

• Run existing expression validation tests
• Run secret extraction tests
• Benchmark to confirm compile-time improvement

Estimated Effort: Small

📈 Success Metrics

This Run

• Findings Generated: 3 (1 new, 2 confirmed recurring)
• Tasks Created: 3
• Files Analyzed: ~15 files across 3 packages
• Success Score: 7/10

Reasoning for Score

• Findings Quality (3/4): One new MEDIUM finding (dead code in time_delta.go) + one confirmed HIGH (sleep without ctx) + one confirmed MEDIUM (regexp in function body). All actionable.
• Coverage (2/3): Covered cli, workflow, parser packages but breadth was moderate given most effort went to confirmation work.
• Task Generation (3/3): All 3 tasks are specific, well-scoped, and small effort.
• Deduction (-1): Strategy yielded more confirmations than new discoveries; the defer-in-loop exploration found only false positives; HTTP body audit showed existing patterns already correct.

📊 Historical Context

Confirmed Fixed Issues (Updated)

Issue	Reported Run	Fixed Run
gateway_logs.go scanner.Buffer lines 336+777	Run 13	Run 20 ✅
mcp_inspect_mcp.go context.Background()	Run 8	Run 20 ✅
copilot_agent*.go regexp moved to package-level	Run 14	Run 16 ✅

Cumulative Statistics

• Total Runs: 20
• Total Findings: 60
• Total Tasks Generated: 60
• Average Success Score: 8.0/10
• Most Successful Strategy: error-patterns-plus-field-registry-audit (score 9, run 3)

🎯 Recommendations

Immediate Actions

1. [HIGH] Fix getLatestWorkflowRunWithRetry — add context parameter and replace time.Sleep with context-aware select. Small effort, big UX improvement (run 9, still open).
2. [MEDIUM] Remove smartFormats dead code block from time_delta.go — add clarifying comment. 5-minute fix.
3. [MEDIUM] Move regexp.MustCompile calls in expression_validation.go and secret_extraction.go to package-level vars. Small effort, measurable performance benefit.

Long-term Improvements

The DependencyGraph race condition (nodes/reverseImports maps accessed from multiple goroutines without mutex, reported run 11) and GetSupportedEngines/GetAllEngines non-deterministic map iteration (reported run 2, still unfixed after 11 reports) are the two longest-running issues in the backlog. Both have clear, simple fixes and high impact on reliability.

🔄 Next Run Preview

Suggested Focus Areas

• Audit pkg/cli/deps_outdated.go: The http.Client per-call-in-loop pattern (run 18) creates N TCP connections for N Go module dependencies — investigate whether sync.WaitGroup-based parallel fetching with a shared client would be appropriate.
• Audit import_field_extractor.go: Six silent JSON parse failures (run 16) — check if these have been addressed.
• Audit pr_command.go:634: os.Chdir without restoration (run 16) — still unfixed for 4 runs.

Strategy Evolution

The dead-code audit proved useful for finding logic bugs in utility functions. Next run could extend this to other time-related or string-parsing utilities in pkg/workflow/ to look for similar ordering/sequencing issues (processing applied in wrong order, conditions that prevent fallback logic from ever firing, etc.).

---

Generated by Sergo - The Serena Go Expert
Run ID: §23072627078
Strategy: context-propagation-revisit-plus-dead-code-audit

AI generated by Sergo - Serena Go Expert · history

• expires on Mar 14, 2026, 10:29 PM UTC

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-03-14T22:29:25.657Z.

Closed by Workflow