Skip to content

Conversation

@CAFxX
Copy link
Contributor

@CAFxX CAFxX commented Nov 7, 2025

Title

Relevant issues

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

  • I have Added testing in the tests/litellm/ directory, Adding at least 1 test is a hard requirement - see details
  • I have added a screenshot of my new test passing locally
  • My PR passes all unit tests on make test-unit
  • My PR's scope is as isolated as possible, it only solves 1 specific problem

Type

🆕 New Feature
🐛 Bug Fix
🧹 Refactoring
📖 Documentation
🚄 Infrastructure
✅ Test

Changes

@vercel
Copy link

vercel bot commented Nov 7, 2025

@CAFxX is attempting to deploy a commit to the CLERKIEAI Team on Vercel.

A member of the Team first needs to authorize it.

@CAFxX CAFxX force-pushed the cafxx-litellm-deadlocks-2 branch from e39fba6 to 5e9c787 Compare November 7, 2025 01:53
@CAFxX CAFxX force-pushed the cafxx-litellm-deadlocks-2 branch from ea2d6b3 to 2cdb95f Compare November 7, 2025 03:28
data={"spend": {"increment": response_cost}},
)
break
except DB_CONNECTION_ERROR_TYPES as e:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why remove the retry logic? @CAFxX

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the request does fail, what would happen ?

Copy link
Contributor Author

@CAFxX CAFxX Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@krrishdholakia the current retry logic seems to be broken... at least this is what our monitoring tells us (one single deadlock in the database immediately causes a spend exception, without any retry -- if the logic was working correctly there should be multiple deadlocks in a row before a single spend exception), and this seems to be confirmed by the definition of DB_CONNECTION_ERROR_TYPES (I actually do not understand at all what those httpx exceptions are, or why they are considered relevant here; I just know that the logic seems to not be working)

FWIW, I am not removing the retry logic; I just moved it to a single place (_handle_db_exception_retriable) - and hopefully fixed it as well to actually handle postgres deadlocks - since it's duplicated with small variations in so many different places

Comment on lines +54 to +55
if isinstance(e, DB_CONNECTION_ERROR_TYPES): # TODO: is this actually needed?
return True
Copy link
Contributor Author

@CAFxX CAFxX Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am keeping this just because it was the old logic. I have no idea, nor a way to practically test, if this is appropriate or not.

Comment on lines +64 to +66
# Unfortunately there does not seem to be a easy way to properly parse that or otherwise detect the specific
# issue, so just match using a regular expression. This is definitely not ideal, but not much we can do about
# it.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least, I could not find a better way. Suggestions are most welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants