[Chore] Log errors from cf-api for better debugging

[mohammedahmed18]

PR Type

Bug fix, Enhancement

---

Description

• Wrap API calls in try/except for HTTPError

• Log JSON or string error messages from API

• Use response.raise_for_status on requests

• Simplify GitHub app install check logic

---

Changes walkthrough 📝

	Relevant files
Error handling	cfapi.py Enhance error handling and logging                                              codeflash/api/cfapi.py Wrapped requests in try/except for HTTP errors Applied response.raise_for_status to catch failures Parsed and logged JSON or plain text errors Simplified is_github_app_installed_on_repo return +24/-11

---

Need help?

Type /help how to ... in the comments thread for any questions about PR-Agent usage.

Check out the documentation for more information.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Narrow Exception Catch Only HTTPError is caught in make_cfapi_request, so other RequestExceptions (e.g., timeouts or connection errors) will propagate uncaught. Consider catching broader exceptions like RequestException. try: if method.upper() == "POST": json_payload = json.dumps(payload, indent=None, default=pydantic_encoder) cfapi_headers["Content-Type"] = "application/json" response = requests.post(url, data=json_payload, headers=cfapi_headers, timeout=60) else: response = requests.get(url, headers=cfapi_headers, timeout=60) response.raise_for_status() return response # noqa: TRY300 Strict Response Check is_github_app_installed_on_repo uses strict equality on response.text to "true", which may fail if the API returns extra whitespace or formatting. Consider normalizing the response text (e.g., strip(), lower()) before comparison. return response.ok and response.text == "true"

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Broaden exception handling Broaden the exception catch to include all request-related errors and capture the exception instance. This ensures connection issues and timeouts are also logged instead of slipping through. codeflash/api/cfapi.py [56] -except requests.exceptions.HTTPError: +except requests.exceptions.RequestException as e: Suggestion importance[1-10]: 8 __ Why: Using RequestException catches all request-related errors (e.g., timeouts, connection issues) and capturing the exception instance ensures proper logging and avoids uncaught cases.	Medium
General	Log HTTP status code Include the HTTP status code in the error log to aid debugging and quickly identify the type of failure. codeflash/api/cfapi.py [68] -logger.error(f"Error making request to Codeflash API: {error_message}") +logger.error(f"Error making request to Codeflash API (status {response.status_code}): {error_message}") Suggestion importance[1-10]: 6 __ Why: Including response.status_code in the error log provides valuable context for debugging API failures without altering logic.	Low
	Log failure in install check Restore logging on failure to help diagnose why the GitHub App check is false by logging status and response text. codeflash/api/cfapi.py [183] -return response.ok and response.text == "true" +if not (response.ok and response.text == "true"): + logger.error(f"GitHub App installation check failed: {response.status_code} - {response.text}") + return False +return True Suggestion importance[1-10]: 6 __ Why: Reintroducing logging on failure helps diagnose why the GitHub App check returns false while preserving the boolean return semantics.	Low

[Saga4]

Q: whats noqa?

[mohammedahmed18]

it's for ignoring ruff linter for this line.

[Saga4]

This is good.