diff --git a/backend/agents.py b/backend/agents.py index ee6d144..bb18f53 100644 --- a/backend/agents.py +++ b/backend/agents.py @@ -149,6 +149,7 @@ async def run_llm_with_tools(system_prompt: str, user_prompt: str): from langchain_mcp_adapters.tools import load_mcp_tools import platform + cmd = "gitnexus.cmd" if platform.system() == "Windows" else "gitnexus" server_params = StdioServerParameters(command=cmd, args=["mcp"]) @@ -314,7 +315,9 @@ async def architect_node(state: AgentState): import subprocess import shutil - repo_dir = os.path.abspath(os.path.join("/tmp", repo.replace("/", "_").replace("\\", "_"))) + repo_dir = os.path.abspath( + os.path.join("/tmp", repo.replace("/", "_").replace("\\", "_")) + ) repo_url = ( f"https://x-access-token:{GITHUB_TOKEN}@github.com/{repo}.git" if GITHUB_TOKEN @@ -342,6 +345,7 @@ async def architect_node(state: AgentState): if not os.path.exists(f"{repo_dir}/.gitnexus"): try: import platform + cmd = "gitnexus.cmd" if platform.system() == "Windows" else "gitnexus" # Run gitnexus asynchronously so it doesn't block the FastAPI event loop analyze_proc = await asyncio.create_subprocess_exec( @@ -784,7 +788,11 @@ async def implementer_node(state: AgentState): ) # Local sync to update the workspace clone on disk - repo_dir = os.path.abspath(os.path.join("/tmp", state["repo_name"].replace("/", "_").replace("\\", "_"))) + repo_dir = os.path.abspath( + os.path.join( + "/tmp", state["repo_name"].replace("/", "_").replace("\\", "_") + ) + ) if os.path.exists(repo_dir): local_path = os.path.join(repo_dir, path) try: diff --git a/backend/main.py b/backend/main.py index b1c3bde..345d517 100644 --- a/backend/main.py +++ b/backend/main.py @@ -59,7 +59,12 @@ async def lifespan(app: FastAPI): # Start the GitNexus MCP server in the background try: import platform - cmd = ["gitnexus.cmd", "serve"] if platform.system() == "Windows" else ["gitnexus", "serve"] + + cmd = ( + ["gitnexus.cmd", "serve"] + if platform.system() == "Windows" + else ["gitnexus", "serve"] + ) gitnexus_process = subprocess.Popen( cmd, stdout=subprocess.DEVNULL, @@ -208,7 +213,7 @@ async def delete_repo_file(repo_name: str, file_path: str): if isinstance(file, list): raise HTTPException( status_code=400, - detail="Directories cannot be deleted directly via this endpoint." + detail="Directories cannot be deleted directly via this endpoint.", ) message = f"Delete {file_path} via AutoMaintainer IDE" diff --git a/ci_failure_issue.md b/ci_failure_issue.md new file mode 100644 index 0000000..8c9f3d0 --- /dev/null +++ b/ci_failure_issue.md @@ -0,0 +1,44 @@ +### Description + +The `Backend CI / lint-and-check` workflow is currently failing during the `Check code formatting with Black` step. This failure is blocking pull requests and release processes. + +From analyzing the workflow run logs (Run ID: `27874267501`), the `black --check .` command exits with code `1` because the following files are not styled according to Black's formatting rules: +- `backend/main.py` +- `backend/agents.py` + +When the CI environment runs `black --check .`, it outputs: +``` +would reformat /home/runner/work/AutoMaintainer/AutoMaintainer/backend/main.py +would reformat /home/runner/work/AutoMaintainer/AutoMaintainer/backend/agents.py + +Oh no! 💥 💔 💥 +2 files would be reformatted, 4 files would be left unchanged. +##[error]Process completed with exit code 1. +``` + +### Proposed Fix + +1. **Format Files Locally:** + Format the offending files using `black` from the root or the backend directory: + ```bash + black backend/main.py backend/agents.py + ``` +2. **Local Lint Validation:** + Before staging and committing, run the local check to ensure compliance: + ```bash + black --check . + ``` +3. **Prevention (Optional but Recommended):** + Add a standard pre-commit hook configuration or document a reminder in `CONTRIBUTING.md` to run `black .` prior to opening a PR. + +### Acceptance Criteria + +1. **Formatting Compliance:** The command `black --check .` must run successfully on the codebase and return exit code `0` with the message `all files would be left unchanged`. +2. **CI Pipeline Pass:** The `Backend CI` workflow must run to completion and show a successful green tick for the `lint-and-check` job on PR and push events. +3. **Professionalism Constraints:** No emojis should be used in any of the codebase changes, commits, or PR descriptions. + +### Acceptance Approach + +When reviewing the Pull Request that addresses this issue: +1. **Local Formatting Run:** Run `black --check .` on the branch to confirm that no files need formatting. +2. **Review CI Run:** Confirm that the GitHub Actions run triggered by the PR successfully builds and passes all steps (including Black formatting and flake8 linting) in the `lint-and-check` job. diff --git a/supabase_inactivity_issue.md b/supabase_inactivity_issue.md new file mode 100644 index 0000000..517f4b7 --- /dev/null +++ b/supabase_inactivity_issue.md @@ -0,0 +1,39 @@ +### Description + +Under the free tier of Supabase, PostgreSQL databases are automatically paused/disabled after 7 days of inactivity (i.e., when no API requests, database queries, or connections occur). Since AutoMaintainer might experience periods of inactivity between agent execution runs, the database can easily be auto-paused by Supabase. + +When the database is paused, the FastAPI backend fails to write/insert execution logs or track active runs. Although backend telemetry writing handles errors gracefully (printing `Supabase insert failed` or `Failed to create run in Supabase`), it fails silently from a user standpoint—resulting in a completely blank dashboard UI and zero historical state tracking during execution. Fixing this requires manual admin intervention (logging into the Supabase console to manually restore the project). + +### Proposed Implementation Architecture + +To ensure high availability and prevent autonomous system degradation, we must implement a keep-alive/ping mechanism along with better status indication: + +1. **Keep-Alive Mechanism (Two Alternative Paths):** + * **Path A: Scheduled GitHub Action (Recommended for zero-runtime cost):** + Create a workflow `.github/workflows/supabase-keepalive.yml` configured to run on a cron schedule (e.g., every 3 days). This workflow will execute a lightweight python script or curl request targeting the Supabase API/REST endpoints (or trigger a database ping query) using the repository secrets `SUPABASE_URL` and `SUPABASE_SERVICE_KEY`. + * **Path B: FastAPI Background Task:** + Implement an async scheduler inside `backend/main.py` (e.g., using `FastAPI` startup events or a background thread) that queries the database (`SELECT 1;`) once every 48 hours to maintain active status. + +2. **Supabase Connection Health Checks:** + * Add a `/healthz/supabase` check endpoint on the FastAPI backend. + * Upon backend boot, perform a quick verification check on the Supabase client connection. If it fails, log a critical warning specifying if the database might be paused. + +3. **Frontend Diagnostics & Feedback:** + * In the Next.js frontend (`dashboard/src/app/page.tsx`), if Supabase is offline or fails to load logs, display a user-friendly banner warning: *"Supabase Database is unreachable or paused. Historical logs and persistence are currently disabled."* + +### Acceptance Criteria + +1. **Keep-Alive Execution:** The keep-alive mechanism must run successfully without crashing and effectively keep the database from pausing. If using a GitHub Action, the workflow must be valid and testable. +2. **Robust Initialization:** If the Supabase client credentials are valid but the connection fails (e.g. database is currently paused), the application must not crash on start. It must log the connection error gracefully. +3. **Health Check Endpoint:** The `/healthz/supabase` endpoint must return a `200 OK` (when connected) or `503 Service Unavailable` with details (when paused or unreachable). +4. **Professionalism Constraints:** No emojis should be used in the commit messages, PR descriptions, issue comments, or source code modifications. + +### Acceptance Approach + +When reviewing the implementation for this issue, the reviewer will follow these validation steps: + +1. **Workflow/Task Code Verification:** Check that the cron pattern is correctly configured to run at least twice a week. +2. **Failure Injection Test:** Simulate a database connection failure (e.g., by temporarily modifying the `SUPABASE_URL` to point to a non-existent host) and verify: + * The backend starts successfully with clean console error logging. + * The frontend doesn't hang indefinitely and displays an appropriate warnings banner to the user. +3. **API Validation:** Query the `/healthz/supabase` endpoint under healthy and simulated error states to verify correct response statuses.