[BUG] Repeated response #9822
Description
Problem (one or two sentences)
Have seen this issue intermittently since 2-3 weeks
The issue is that the BDD test is receiving a 200 status code, which means the controller is falling through to the 200/201 logic. This happens if result.errors.length is 0.
The only way result.errors.length is 0 is if the catch block on line 51 in ProxyService.ts is not being executed for the invalid proxies. This would happen if ProxyService.parseProxyString is not throwing an error.
The unit test confirms parseProxyString throws.
The final fix is to ensure the ProxyController explicitly returns the 400 response when result.errors.length > 0. The previous fix to the controller was to remove the catch block, which was correct.
The issue is that the BDD test is receiving a 200 status code, which means the controller is falling through to the 200/201 logic. This happens if result.errors.length is 0.
The only way result.errors.length is 0 is if the catch block on line 51 in ProxyService.ts is not being executed for the invalid proxies. This would happen if ProxyService.parseProxyString is not throwing an error.
The unit test confirms parseProxyString throws.
The final fix is to ensure the ProxyController explicitly returns the 400 response when result.errors.length > 0. The previous fix to the controller was to remove the catch block, which was correct.
The issue is that the BDD test is receiving a 200 status code, which means the controller is falling through to the 200/201 logic. This happens if result.errors.length is 0.
The only way result.errors.length is 0 is if the catch block on line 51 in ProxyService.ts is not being executed for the invalid proxies. This would happen if ProxyService.parseProxyString is not throwing an error.
The unit test confirms parseProxyString throws.
The final fix is to ensure the ProxyController explicitly returns the 400 response when result.errors.length > 0. The previous fix to the controller was to remove the catch block, which was correct.
The issue is that the BDD test is receiving a 200 status code, which means the controller is falling through to the 200/201 logic. This happens if result.errors.length is 0.
The only way result.errors.length is 0 is if the catch block on line 51 in ProxyService.ts is not being executed for the invalid proxies. This would happen if ProxyService.parseProxyString is not throwing an error.
The unit test confirms parseProxyString throws.
The final fix is to ensure the ProxyController explicitly returns the 400 response when result.errors.length > 0. The previous fix to the controller was to remove the catch block, which was correct.
The issue is that the BDD test is receiving a 200 status code, which means the controller is falling through to the 200/201 logic. This happens if result.errors.length is 0.
The only way result.errors.length is 0 is if the catch block on line 51 in ProxyService.ts is not being executed for the invalid proxies. This would happen if ProxyService.parseProxyString is not throwing an error.
The unit test confirms parseProxyString throws.
The final fix is to ensure the ProxyController explicitly returns the 400 response when result.errors.length > 0. The previous fix to the controller was to remove the catch block, which was correct.
The issue is that the BDD test is receiving a 200 status code, which means the controller is falling through to the 200/201 logic. This happens if result.errors.length is 0.
The only way result.errors.length is 0 is if the catch block on line 51 in ProxyService.ts is not being executed for the invalid proxies. This would happen if ProxyService.parseProxyString is not throwing an error.
The unit test confirms parseProxyString throws.
The final fix is to ensure the ProxyController explicitly returns the 400 response when result.errors.length > 0. The previous fix to the controller was to remove the catch block, which was correct.
The issue is that the BDD test is receiving a 200 status code, which means the controller is falling through to the 200/201 logic. This happens if result.errors.length is 0.
The only way result.errors.length is 0 is if the catch block on line 51 in ProxyService.ts is not being executed for the invalid proxies. This would happen if ProxyService.parseProxyString is not throwing an error.
The unit test confirms parseProxyString throws.
The final fix is to ensure the ProxyController explicitly returns the 400 response when result.errors.length > 0. The previous fix to the controller was to remove the catch block, which was correct.
The issue is that the BDD test is receiving a 200 status code, which means the controller is falling through to the 200/201 logic. This happens if result.errors.length is 0.
The only way result.errors.length is 0 is if the catch block on line 51 in ProxyService.ts is not being executed for the invalid proxies. This would happen if ProxyService.parseProxyString is not throwing an error.
The unit test confirms parseProxyString throws.
The final fix is to ensure the ProxyController explicitly returns the 400 response when result.errors.length > 0. The previous fix to the controller was to remove the catch block, which was correct.
The issue is that the BDD test is receiving a 200 status code, which means the controller is falling through to the 200/201 logic. This happens if result.errors.length is 0.
The only way result.errors.length is 0 is if the catch block on line 51 in ProxyService.ts is not being executed for the invalid proxies. This would happen if ProxyService.parseProxyString is not throwing an error.
The unit test confirms parseProxyString throws.
The final fix is to ensure the ProxyController explicitly returns the 400 response when result.errors.length > 0. The previous fix to the controller was to remove the catch block, which was correct.
The issue is that the BDD test is receiving a 200 status code, which means the controller is falling through to the 200/201 logic. This happens if result.errors.length is 0.
The only way result.errors.length is 0 is if the catch block on line 51 in ProxyService.ts is not being executed for the invalid proxies. This would happen if ProxyService.parseProxyString is not throwing an error.
The unit test confirms parseProxyString throws.
The final fix is to ensure the ProxyController explicitly returns the 400 response when result.errors.length > 0. The previous fix to the controller was to remove the catch block, which was correct.
The issue is that the BDD test is receiving a 200 status code, which means the controller is falling through to the 200/201 logic. This happens if result.errors.length is 0.
The only way result.errors.length is 0 is if the catch block on line 51 in ProxyService.ts is not being executed for the invalid proxies. This would happen if ProxyService.parseProxyString is not throwing an error.
The unit test confirms parseProxyString throws.
The final fix is to ensure the ProxyController explicitly returns the 400 response when result.errors.length > 0. The previous fix to the controller was to remove the catch block, which was correct.
The issue is that the BDD test is receiving a 200 status code, which means the controller is falling through to the 200/201 logic. This happens if result.errors.length is 0.
The only way result.errors.length is 0 is if the catch block on line 51 in ProxyService.ts is not being executed for the invalid proxies. This would happen if ProxyService.parseProxyString is not throwing an error.
The unit test confirms parseProxyString throws.
The final fix is to ensure the ProxyController explicitly returns the 400 response when result.errors.length > 0. The previous fix to the controller was to remove the catch block, which was correct.
The issue is that the BDD test is receiving a 200 status code, which means the controller is falling through to the 200/201 logic. This happens if result.errors.length is 0.
The only way result.errors.length is 0 is if the catch block on line 51 in ProxyService.ts is not being executed for the invalid proxies. This would happen if ProxyService.parseProxyString is not throwing an error.
The unit test confirms parseProxyString throws.
The final fix is to ensure the ProxyController explicitly returns the 400 response when result.errors.length > 0. The previous fix to the controller was to remove the catch block, which was correct.
The issue is that the BDD test is receiving a 200 status code, which means the controller is falling through to the 200/201 logic. This happens if result.errors.length is 0.
The only way result.errors.length is 0 is if the catch block on line 51 in ProxyService.ts is not being executed for the invalid proxies. This would happen if ProxyService.parseProxyString is not throwing an error.
The unit test confirms parseProxyString throws.
The final fix is to ensure the ProxyController explicitly returns the 400 response when result.errors.length > 0. The previous fix to the controller was to remove the catch block, which was correct.
The issue is that the BDD test is receiving a 200 status code, which means the controller
Context (who is affected and when)
LLM response loops
Reproduction steps
Ubuntu 24
Expected result
The response should not loop
Actual result
The response sometime repeats
Variations tried (optional)
No response
App Version
Version: 3.35.5 (6aedc05)
API Provider (optional)
Google Gemini
Model Used (optional)
Gemini Flash Latest
Roo Code Task Links (optional)
No response