Bug fix for trailing slash error when using LiteLLM provider

[kcwhite]

Related GitHub Issue

Closes: #4273

Description

This PR fixes an issue where the LiteLLM model fetcher would fail when the base URL contained a trailing slash. The implementation:

1. Normalizes the base URL by removing any trailing slash before constructing the API endpoint URL
2. Adds a clear comment explaining the normalization step
3. Includes a new test case specifically to verify this behavior

The fix is minimal and focused on ensuring that URLs are properly formatted regardless of user input format, preventing the creation of invalid URLs with double slashes (e.g., "http://localhost:4000//v1/model/info").

Test Procedure

1. Unit Tests: Added a specific test case in src/api/providers/fetchers/__tests__/litellm.test.ts that verifies base URLs with trailing slashes are handled correctly.

2. Manual Testing:

   • Configure Roo Code with a LiteLLM provider using a base URL with trailing slash (e.g., "http://localhost:4000/")
   • Verify that the connection works and models are fetched correctly
   • Check browser network tab to confirm the correct URL is being called (without double slashes)

3. To Reproduce the Original Issue:

   • Revert the fix
   • Configure Roo Code with a LiteLLM provider using a base URL with trailing slash
   • Observe that the connection fails due to malformed URL

Type of Change

• 🐛 Bug Fix: Non-breaking change that fixes an issue.
• ✨ New Feature: Non-breaking change that adds functionality.
• 💥 Breaking Change: Fix or feature that would cause existing functionality to not work as expected.
• ♻️ Refactor: Code change that neither fixes a bug nor adds a feature.
• 💅 Style: Changes that do not affect the meaning of the code (white-space, formatting, etc.).
• 📚 Documentation: Updates to documentation files.
• ⚙️ Build/CI: Changes to the build process or CI configuration.
• 🧹 Chore: Other changes that don't modify src or test files.

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Code Quality:
  • My code adheres to the project's style guidelines.
  • There are no new linting errors or warnings (npm run lint).
  • All debug code (e.g., console.log) has been removed.
• Testing:
  • New and/or updated tests have been added to cover my changes.
  • All tests pass locally (pnpm test).
  • The application builds successfully with my changes.
• Branch Hygiene: My branch is up-to-date (rebased) with the main branch.
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Changeset: A changeset has been created using npm run changeset if this PR includes user-facing changes or dependency updates.
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

N/A - This is a backend fix with no UI changes.

Documentation Updates

• No documentation updates are required.

Additional Notes

This is a small but important fix that ensures users can successfully connect to LiteLLM servers regardless of how they format the base URL in their configuration.

Get in Touch

Discord: chuck_33620

---

Important

Fixes URL formatting issue in LiteLLM provider by normalizing base URL to remove trailing slashes, preventing invalid URLs.

• Behavior:
  • Fixes URL formatting issue in getLiteLLMModels() in litellm.ts by normalizing base URL to remove trailing slashes.
  • Prevents creation of invalid URLs with double slashes.
• Testing:
  • Adds test case in litellm.test.ts to verify handling of base URLs with trailing slashes.
• Documentation:
  • Adds comment in litellm.ts explaining URL normalization step.

^{This description was created by for 9d59c76cc1f530329c2c336c8f7a535fb5bfc3c2. You can customize this summary. It will automatically update as commits are pushed.}

[daniel-lxs]

Would it make sense to use the URL constructor (e.g., new URL(pathSegment, baseUrl).href) for joining the base URL and path? It inherently handles scenarios with or without trailing slashes on the baseUrl, potentially removing the need for this manual normalization and leading to a cleaner implementation.

[kcwhite]

I like it, I'll make the change

[daniel-lxs]

Hey @kcwhite, I'm requesting changes to restore the unintentionally deleted .rooignore and .roomodes files.

[daniel-lxs]

Hey @kcwhite,
It seems like the .rooignore and .roomodes files got moved to the /.roo/ folder. They are supposed to be in the root directory. Can you please restore them?

[daniel-lxs]

Perfect, thank you for addressing the review comments.

Looks good to me now!

[daniel-lxs]

Cleaned up the history a bit so we can review this easily, since you had a bunch of unrelated commits from main on your PR.

[kcwhite]

Cleaned up the history a bit so we can review this easily, since you had a bunch of unrelated commits from main on your PR.

Sorry Daniel, I'm educating myself on the proper workflow for open source contributions. My future commits should be cleaner since I will rebase rather than merge.

[daniel-lxs]

@kcwhite
Sorry I was a bit blunt there, I was doing a couple of things at the same time.

No worries, just wanted to get your PR ready for review quickly.

We all learn at some point.

Thank you and sorry.

[kcwhite]

Blunt is my native tongue, you were hardly blunt. 😀

My team prefers merges, fewer conflicts, so I'm having to re-educate myself to use rebase again.