Skip to content

Conversation

@harshitashankar
Copy link

Describe the changes that are made

  • When running an application with Keploy in record mode, if the application attempts to connect to an external service that is unreachable (e.g., a configuration service, API endpoint, or database), the application crashes or hangs instead of gracefully handling the connection failure. In cases when the unreachable endpoint is not crucial for app startup, app would crash even when it does not need to.

Links & References

Closes: #[issue number that will be closed through this PR]

  • NA (if very small change like typo, linting, etc.)

🔗 Related PRs

  • NA

🐞 Related Issues

  • NA

📄 Related Documents

  • NA

What type of PR is this? (check all applicable)

  • 📦 Chore
  • 🍕 Feature
  • 🐞 Bug Fix
  • 📝 Documentation Update
  • 🎨 Style
  • 🧑‍💻 Code Refactor
  • 🔥 Performance Improvements
  • ✅ Test
  • 🔁 CI
  • ⏩ Revert

Added e2e test pipeline?

  • 👍 yes
  • 🙅 no, because they aren't needed
  • 🙋 no, because I need help

Added comments for hard-to-understand areas?

  • 👍 yes
  • 🙅 no, because the code is self-explanatory

Added to documentation?

  • 📜 README.md
  • 📓 Wiki
  • 🙅 no documentation needed

Are there any sample code or steps to test the changes?

  • 👍 yes, mentioned below
  • 🙅 no, because it is not needed

Self Review done?

  • ✅ yes
  • ❌ no, because I need help

Any relevant screenshots, recordings or logs?

  • NA

🧠 Semantics for PR Title & Branch Name

Please ensure your PR title and branch name follow the Keploy semantics:

📌 PR Semantics Guide
📌 Branch Semantics Guide

Examples:

  • PR Title: fix: patch MongoDB document update bug
  • Branch Name: feat/#1-login-flow (You may skip mentioning the issue number in the branch name if the change is small and the PR description clearly explains it.)

Additional checklist:

@github-actions
Copy link

github-actions bot commented Dec 23, 2025

CLA Assistant Lite bot:
Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.


I have read the CLA Document and I hereby sign the CLA


1 out of 2 committers have signed the CLA.
@gouravkrosx
❌ @harshita.shankar
harshita.shankar seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
You can retrigger this bot by commenting recheck in this Pull Request

@github-actions
Copy link

The CLA check failed. Please ensure you have:

  • Signed the CLA by commenting 'I have read the CLA Document and I hereby sign the CLA.'
  • Used the correct email address in your commits (matches the one you used to sign the CLA).

After fixing these issues, comment 'recheck' to trigger the workflow again.

@github-actions
Copy link

The CLA check failed. Please ensure you have:

  • Signed the CLA by commenting 'I have read the CLA Document and I hereby sign the CLA.'
  • Used the correct email address in your commits (matches the one you used to sign the CLA).

After fixing these issues, comment 'recheck' to trigger the workflow again.

if err != nil {
utils.LogError(logger, err, "failed to dial the conn to destination server", zap.Uint32("proxy port", p.Port), zap.String("server address", dstAddr))
// Send HTTP error response if we've already read an HTTP request
p.sendHTTPErrorResponse(srcConn, initialBuf, logger, 500, "Internal Server Error")
Copy link
Member

Choose a reason for hiding this comment

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

We can’t simply send an HTTP response to the srcConn without knowing whether the client is speaking HTTP, as this can cause an immediate protocol violation. A non-HTTP client (like SSH or a database client) will not understand the response, leading to a connection failure with a cryptic error like “Connection reset by peer” or “Protocol error.”

@gouravkrosx
Copy link
Member

@harshitashankar Instead of adding an extra port-based check, we should refactor the logic so that we start listening to both the client and the server concurrently. Whichever side sends the first initial buffer can then be used to detect the protocol. Since in MySQL the server sends the first packet, we can inspect that buffer — if it’s MySQL, proceed with the MySQL flow; otherwise, fall back to the generic parser.

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