Conversation
WalkthroughThe pull request transitions the application's configuration loading system from the Viper library to the Adder library across both server and agent components. Additionally, the CI/CD workflow is refined to ensure build and push operations only execute for main branch commits or tagged releases, preventing unnecessary builds on pull requests. Both config files now include post-load logging initialization and debug-level JSON pretty-printing of loaded configurations. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
cmd/silo-proxy-server/config.go (1)
70-75:⚠️ Potential issue | 🟠 MajorPotential exposure of sensitive configuration in debug logs.
When
LOG_LEVEL_DEBUGis set, the entire config struct is pretty-printed as JSON. This may expose sensitive values such as JWT secrets, database credentials, or API keys in logs.Consider redacting sensitive fields before logging, or use a structured logger that supports field masking.
cmd/silo-proxy-agent/config.go (1)
68-74:⚠️ Potential issue | 🟠 MajorSame sensitive data exposure concern as server config.
The debug logging of the entire config struct could expose sensitive values. The same mitigation (redacting sensitive fields) should be applied here.
🤖 Fix all issues with AI agents
In `@cmd/silo-proxy-agent/config.go`:
- Around line 52-53: Remove the two unused environment bindings that were
copy-pasted from the server config: delete the calls to
adder.BindEnv("telegram.token", "TELEGRAM_TOKEN") and
adder.BindEnv("openrouter.apiKey", "OPENROUTER_API_KEY") in config
initialization so the agent only keeps the required config sections
(config.Grpc, config.Local, config.Log); this removes unused dependencies and
avoids binding unused env vars.
In `@cmd/silo-proxy-server/config.go`:
- Line 12: The code imports the early-stage github.com/lwlee2608/adder package
without a pinned version and without an abstraction; update go.mod to pin the
dependency to v0.1.0 and introduce a tiny abstraction layer (e.g., define an
AdderClient interface and a concrete adderImpl that wraps
github.com/lwlee2608/adder calls) so callers use AdderClient rather than the
adder package directly (place the wrapper in config.go or a new adder_adapter.go
and implement methods that mirror the used adder functions).
🧹 Nitpick comments (2)
.github/workflows/build-server.yml (2)
46-46: Redundant step-level conditions within gated job.The job-level
ifon line 46 already ensures this job only runs formainbranch or tags. The identical conditions on lines 63, 71, and 97 are redundant and add maintenance overhead.Consider removing the step-level
ifconditions since the job gate already provides the same protection.♻️ Proposed simplification
- name: Log in to docker.io - if: github.event_name != 'pull_request' && (github.ref == 'refs/heads/main' || startsWith(github.ref, 'refs/tags/')) uses: docker/login-action@5e57cd118135c172c3672efd75eb46360885c0ef # v3.6.0 with: registry: docker.io username: eternis password: ${{ secrets.DOCKER_PAT }} - name: Log in to GHCR - if: github.event_name != 'pull_request' && (github.ref == 'refs/heads/main' || startsWith(github.ref, 'refs/tags/')) uses: docker/login-action@5e57cd118135c172c3672efd75eb46360885c0ef # v3.6.0 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }}And for the push parameter:
- push: ${{ github.event_name != 'pull_request' && (github.ref == 'refs/heads/main' || startsWith(github.ref, 'refs/tags/')) }} + push: trueAlso applies to: 63-63, 71-71, 97-97
106-106: Same redundancy applies to build-agent job.The
build-agentjob has the same pattern of redundant step-level conditions that duplicate the job-level gate. Same simplification can be applied here.Also applies to: 123-123, 131-131, 157-157
| _ = adder.BindEnv("telegram.token", "TELEGRAM_TOKEN") | ||
| _ = adder.BindEnv("openrouter.apiKey", "OPENROUTER_API_KEY") |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if telegram or openrouter are referenced in agent code
rg -i 'telegram|openrouter' cmd/silo-proxy-agent/ --type go -cRepository: EternisAI/silo-proxy
Length of output: 96
🏁 Script executed:
#!/bin/bash
# Search for telegram or openrouter usage in agent code, excluding just the BindEnv declarations
rg -i 'telegram|openrouter' cmd/silo-proxy-agent/ --type go -B 2 -A 2Repository: EternisAI/silo-proxy
Length of output: 436
🏁 Script executed:
#!/bin/bash
# Check what the agent actually does - look at main.go and see how config is used
cat -n cmd/silo-proxy-agent/main.go | head -50
# Also search for any viper.Get calls that might read telegram/openrouter config
rg 'Get\(.*telegram|Get\(.*openrouter' cmd/silo-proxy-agent/ --type goRepository: EternisAI/silo-proxy
Length of output: 1804
🏁 Script executed:
#!/bin/bash
# Find all config field accesses in agent code
rg 'config\.' cmd/silo-proxy-agent/ --type go | grep -v Binary | cut -d: -f2 | sort -uRepository: EternisAI/silo-proxy
Length of output: 233
Remove unnecessary environment bindings for telegram and openrouter.
The telegram.token and openrouter.apiKey bindings on lines 52-53 are never used by the agent. The agent only requires config.Grpc, config.Local, and config.Log configuration sections. These bindings are copy-paste remnants from the server config and should be removed.
🤖 Prompt for AI Agents
In `@cmd/silo-proxy-agent/config.go` around lines 52 - 53, Remove the two unused
environment bindings that were copy-pasted from the server config: delete the
calls to adder.BindEnv("telegram.token", "TELEGRAM_TOKEN") and
adder.BindEnv("openrouter.apiKey", "OPENROUTER_API_KEY") in config
initialization so the agent only keeps the required config sections
(config.Grpc, config.Local, config.Log); this removes unused dependencies and
avoids binding unused env vars.
| "github.com/EternisAI/silo-proxy/internal/db" | ||
| "github.com/joho/godotenv" | ||
| "github.com/spf13/viper" | ||
| "github.com/lwlee2608/adder" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check the adder library GitHub repo
curl -s "https://api.github.com/repos/lwlee2608/adder" | jq '{name, description, stargazers_count, open_issues_count, created_at, updated_at, license, is_fork}'Repository: EternisAI/silo-proxy
Length of output: 429
🌐 Web query:
github.com/lwlee2608/adder configuration library stability
💡 Result:
The lwlee2608/adder Go configuration library looks early-stage / not yet “stable” in the semver sense:
- It has only one published tag:
v0.1.0(Feb 8, 2026), and no GitHub Releases published. [1][2] - The repo history is small (15 commits total), with initial development starting Jan 22, 2026 and a cluster of updates on Feb 8, 2026. [3]
- It does have CI set up (GitHub Actions workflow runs are present) and includes tests/examples, which is a positive sign for basic reliability—but it’s still a new, lightly adopted project (very low stars/forks). [4][5]
Practical stability guidance: treat it as “pre-1.0 API may change”; if you use it, pin to v0.1.0 and keep it behind a small abstraction so you can swap/adjust later. [1]
Sources:
[1] Git tags showing v0.1.0 date (Feb 8, 2026) — (github.com)
[2] GitHub Releases page (“There aren’t any releases here”) — (github.com)
[3] Commit history showing 15 commits and dates (Jan 22, 2026; Feb 8, 2026) — (github.com)
[4] Actions page showing CI workflows/runs — (github.com)
[5] Repo README describing scope/features — (github.com)
Citations:
- 1: https://github.com/lwlee2608/adder/tags
- 2: https://github.com/lwlee2608/adder/releases
- 3: https://github.com/lwlee2608/adder/commits/main/
- 4: https://github.com/lwlee2608/adder/actions
- 5: https://github.com/lwlee2608/adder
The adder library is in pre-1.0 stage with minimal adoption—pin the version and consider an abstraction layer.
The github.com/lwlee2608/adder library is very early-stage (created Jan 22, 2026, only v0.1.0 released Feb 8, 2026). With 1 star and no GitHub Releases, it has negligible real-world adoption. While CI and tests are present, pre-1.0 libraries often introduce breaking changes.
Recommendations:
- Explicitly pin to
v0.1.0ingo.modto prevent unexpected upgrades - Wrap adder calls in a small configuration abstraction so you can quickly swap libraries if issues arise
🤖 Prompt for AI Agents
In `@cmd/silo-proxy-server/config.go` at line 12, The code imports the early-stage
github.com/lwlee2608/adder package without a pinned version and without an
abstraction; update go.mod to pin the dependency to v0.1.0 and introduce a tiny
abstraction layer (e.g., define an AdderClient interface and a concrete
adderImpl that wraps github.com/lwlee2608/adder calls) so callers use
AdderClient rather than the adder package directly (place the wrapper in
config.go or a new adder_adapter.go and implement methods that mirror the used
adder functions).
1 participant
Summary by CodeRabbit