fix: resolve alias correctly in generate_refactoring_code

[abhiramvsmg]

generate_refactoring_code passed repo to _get_repo(session, repo) even though _resolve_repo_context(repo) had already resolved the alias and scoped the session to that one repository. This caused LookupError: Repository not found for workspace aliases that differ from the repo's directory basename, since _get_repo only matches on paths, IDs, and Repository.name.

Dropped the repo argument, matching the same fix already applied to get_health in #865.

Added test_generate_refactoring_code_resolves_alias_different_from_repo_name using the existing frontend/web-client alias fixture. Full test suite passes (28/28 in test_mcp_workspace.py).

Fixes #880

[repowise-bot]

✅ Health: 7.6 (unchanged)

📋 At a glance
2 hotspots touched · 1 file with recent fix history.

Files & modules (2)

• packages (1 file)
  • .../mcp_server/tool_refactoring.py
• tests (1 file)
  • .../server/test_mcp_workspace.py

🩹 Review priority _{(files here with the most recent bug-fix history — defects cluster, so review these first)}

• .../server/test_mcp_workspace.py — fixed 2× in the last ~6 months

🔎 More signals (1)

🔥 Hotspots touched (2)

• .../server/test_mcp_workspace.py — 3 commits/90d, 0 dependents · primary owner: Raghav Chamadiya (89%)
• .../mcp_server/tool_refactoring.py — 2 commits/90d, 1 dependents · primary owner: Raghav Chamadiya (100%)

---

📊 Full report · ⭐ Star Repowise · 📥 Install bot · Last updated 2026-07-17 10:09 UTC
_{Silence on a single PR with [skip repowise] in the title · Per-repo toggle on repowise.dev/settings?tab=bot}

[swati510]

Thank you for adding a regression test, and I confirmed that it does fail with the original LookupError when the production fix is reverted, so it genuinely guards the bug.

Could I suggest tightening the assertion to assert result["error"] == "not_found"? The tool has three different early returns that all set an error key, and only not_found proves that execution actually got past the repository lookup that this pull request fixes. In particular, llm_enrichment_enabled currently defaults to True when the repository has no configuration file, which is why the test reaches the lookup at all today. If that default were ever flipped, the tool would return error: "disabled" before touching the database, the test would still pass, and it would quietly stop testing anything.

[swati510]

This is outside the scope of your fix, so please feel free to leave it for a separate change, but I noticed while reviewing that generate_refactoring_code does not guard against repo="all". At packages/server/src/repowise/server/mcp_server/tool_refactoring.py line 86 it calls _resolve_repo_context(repo) directly, and in workspace mode that helper deliberately raises a ValueError for repo="all" rather than handling it, on the grounds that each tool should decide for itself what "all repositories" means. Seven other tools guard for this first and return a readable error dictionary by calling _unsupported_repo_all(...), among them get_risk, get_symbol, get_why, get_context and get_answer. Without that guard, generate_refactoring_code(suggestion_id=..., repo="all") raises an uncaught ValueError instead of returning a readable error dictionary, and I confirmed that by calling it. It is the same family of workspace handling gap that this pull request closes, and it is only a couple of lines if you would like to include it.