fix: Compose generator should detect duplicate service names at generate-time (#850) #1053
No reviewers
Labels
No labels
action
backlog
blocked
bug-report
cannot-reproduce
in-progress
in-triage
needs-triage
prediction/actioned
prediction/dismissed
prediction/unreviewed
priority
rejected
reproduced
tech-debt
underspecified
vision
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: disinto-admin/disinto#1053
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/issue-850-4"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes #850
Changes
c9e8fb5b6eto1170ecb2f0AI Review
Summary
The duplicate-detection logic in
generators.shis correct and the smoke-test addition (section 8 insmoke-init.sh) validates the happy path properly via a subshell. However, the new unit test file ships with a state-management bug that causes Tests 2 and 3 to fail when run.Blocker
high
lib/generators.sh:30-31/tests/test-duplicate-service-detection.sh:_seen_servicesand_service_sourcesare declared at module scope and never reset between calls to_generate_compose_impl.test-duplicate-service-detection.shsourcesgenerators.shonce (line 90) and then calls_generate_compose_implthree times in the same process. After Test 1 completes (correctly detecting theagents-llamaduplicate),_seen_servicesstill holdsforgejo,woodpecker, …,agents-llama. When Test 2 calls_generate_compose_impl, the first_record_service "forgejo" "base compose template"call returns 1 and printsERROR: Duplicate service name 'forgejo' detected;grep -q "Duplicate"matches and Test 2 callsfail, settingFAILED=1. Test 3 inherits the same poisoned state. The smoke test avoids this because it runs inside a subshell. CI doesn't catch it because.woodpecker/smoke-init.ymlonly runsbash tests/smoke-init.sh, nottest-duplicate-service-detection.sh.Fix: reset the arrays at the top of
_generate_compose_implbefore the base-service registrations:Notes (non-blocking)
low
lib/generators.sh:479: TheENABLE_LLAMA_AGENTblock comment says the flag "was removed in #846 but kept for duplicate detection testing". Re-adding ~55 lines of compose service generation for a removed feature solely to exercise the test scenario is scope creep. The TOML-TOML path (Test 3) already demonstrates the detection logic without requiring a legacy code path. Consider whether the smoke scenario should instead use two TOML files with the same agent name, which is the only production-reachable duplicate path post-#846.low
tests/test-duplicate-service-detection.sh: The file is not referenced by any CI step; wiring it in after fixing the state bug would increase coverage.Verdict
REQUEST_CHANGES — test-duplicate-service-detection.sh fails when run: global _seen_services state from Test 1 bleeds into Test 2 and Test 3
Reviewed at
1170ecb| AGENTS.mdAI Review: REQUEST_CHANGES — test-duplicate-service-detection.sh fails when run: global _seen_services state from Test 1 bleeds into Test 2 and Test 3
AI Re-review (round 2)
Previous Findings\n- high
lib/generators.sh:_seen_services/_service_sourcesnever reset between calls → FIXED: lines 317–318 reset both arrays at the top of_generate_compose_impl, before any base-service registration. Sequential calls intest-duplicate-service-detection.shnow start clean.\n\n### Notes (carried forward, non-blocking)\n- lowlib/generators.sh:479:ENABLE_LLAMA_AGENTlegacy block remains for test coverage; still scope creep vs. the TOML–TOML path, but non-blocking.\n- lowtests/test-duplicate-service-detection.sh: file still not wired into CI; worthwhile follow-up but does not block this fix.Verdict
APPROVE — State reset fix is correct and in the right place; prior blocker closed
Reviewed at
0f91efc| Previous:1170ecb| AGENTS.mdAI Re-review (round 2): APPROVE — State reset fix is correct and in the right place; prior blocker closed