Skip to content

chore: sync from forge - ESLint 9 upgrade session#39

Open
namastex888 wants to merge 4 commits into
mainfrom
fix/publish-version-check
Open

chore: sync from forge - ESLint 9 upgrade session#39
namastex888 wants to merge 4 commits into
mainfrom
fix/publish-version-check

Conversation

@namastex888
Copy link
Copy Markdown

@namastex888 namastex888 commented Dec 18, 2025

Summary

Synced changes from automagik-forge during ESLint 9 upgrade session.

Related forge PR: automagik-dev/forge#325

Changes

  • .github/workflows/check-release-intent.yml - workflow updates
  • crates/db/migrations/ - task attempt config type fix
  • crates/executors/src/executors/claude.rs - executor changes
  • crates/local-deployment/src/container.rs - container updates
  • crates/server/src/main.rs - server updates
  • crates/server/src/routes/task_attempts.rs - route changes
  • crates/server/src/routes/tasks.rs - route changes
  • crates/utils/Cargo.toml - dependency updates
  • crates/utils/src/shell.rs - shell utility changes

Test Plan

  • CI passes

ESLint 9 flat config migration:
- Migrate from .eslintrc.cjs to eslint.config.js flat config format
- Upgrade eslint 8.57→9.39, @typescript-eslint/* 7.18→8.50
- Replace react-spring with @react-spring/web (eliminates 9 deprecated deps)
- Fix 4 lint errors caught by stricter v9 rules

Dependency improvements:
- Eliminates 14 deprecated subdependencies from pnpm install warnings
- Only 2 remain (from click-to-react-component and forge-inspector)

Performance and cleanup:
- Wrap TaskCard in memo() to prevent unnecessary re-renders
- Remove debug console.logs from TaskKanbanBoard, TaskFollowUpSection
- Simplify useTaskCompletionNotification (Set vs Map, clearer logic)
- Fix useConversationHistory to emit entries when process completes
- Extract primitive from branchStatus for stable useMemo deps
@gemini-code-assist
Copy link
Copy Markdown

Summary of Changes

Hello @namastex888, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request integrates a series of changes from an upstream forge, primarily focusing on critical performance enhancements and a database schema correction. The updates aim to reduce perceived latency for task initiation, optimize resource utilization during startup, and ensure data integrity within the forge_task_attempt_config table by fixing a type mismatch.

Highlights

  • Performance Optimizations: Implemented several key performance improvements, including caching PATH resolution, delaying file search cache warming, and offloading task attempt initiation to background processes to reduce perceived latency.
  • Database Schema Fix: Corrected a type mismatch in the forge_task_attempt_config table, changing task_attempt_id to BLOB to ensure proper foreign key constraints and prevent insertion errors.
  • Dependency Updates: Upgraded the claude-code executor version and enabled the sync feature for the tokio crate to support new concurrency patterns.
  • Background Task Processing: Modified task creation and attempt routes to immediately return HTTP responses while processing the actual task startup in the background, significantly reducing perceived latency for users.
Ignored Files
  • Ignored by pattern: .github/workflows/** (1)
    • .github/workflows/check-release-intent.yml
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

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

Code Review

This pull request introduces several significant performance improvements and a database migration fix. The changes to move long-running operations like starting a task attempt into background tasks will greatly improve API responsiveness. The pre-warming of the PATH resolution cache is also a smart optimization to reduce latency for the first task. The database migration correctly addresses a type mismatch for foreign keys. My only suggestion is to restore some logging that was removed during a refactoring in the shell utility, as it could be valuable for debugging user environment issues.

Comment thread crates/utils/src/shell.rs Outdated
);
return None;
}
Ok(Err(_)) | Err(_) => return None,
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

medium

The error handling for wait_with_output and timeouts has been simplified to return None without logging. While this is more concise, it removes valuable debugging information if PATH resolution fails for a specific shell. Consider reintroducing logging at the debug level to aid in troubleshooting user environment issues without being too noisy.

            Ok(Err(err)) => {
                tracing::debug!("Failed to get PATH from {}: {}", shell.display(), err);
                return None;
            }
            Err(_) => {
                tracing::debug!("Timed out getting PATH from {}", shell.display());
                return None;
            }

@namastex888
Copy link
Copy Markdown
Author

@codex review this pr

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +621 to +624
});

// Optimistically return true - attempt is starting in background
let is_attempt_running = true;
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P1 Badge create_task_and_start always reports attempt running

The endpoint now spawns start_attempt in the background but immediately sets is_attempt_running = true in the response. If start_attempt fails (e.g., container creation or git setup error), the client still gets a success response indicating an in-progress attempt with no way to detect the failure because the result is only logged inside the spawned task. Previously this flag reflected the start result; now it is always true, so the UI can show a running attempt that never starts when the background call errors.

Useful? React with 👍 / 👎.

The P0 performance optimization (42s -> <1s HTTP response) introduced
silent failures: start_attempt() runs in tokio::spawn() with errors
only logged, returning is_attempt_running=true before knowing if the
attempt actually started.

This fix:
- Add `Initializing` status to ExecutionProcessStatus enum
- Create ExecutionProcess with Initializing status BEFORE spawning
- Transition to Running on success, Failed on error
- SSE automatically pushes status changes to clients

Also fixes logging:
- main.rs: Log success/failure of PATH cache warming (not just "warmed")
- shell.rs: Restore debug/warn logging for shell failures/timeouts
@namastex888 namastex888 force-pushed the fix/publish-version-check branch from ac283f9 to 1ca961f Compare December 19, 2025 00:30
@namastex888
Copy link
Copy Markdown
Author

@codex review this pr

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +262 to +266
run_reason: ExecutionProcessRunReason::CodingAgent,
},
execution_process_id,
None, // before_head_commit captured during actual startup
ExecutionProcessStatus::Initializing,
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P0 Badge Initializing status violates execution_processes schema

New task creation now inserts execution processes with ExecutionProcessStatus::Initializing, but the execution_processes.status column is constrained to running/completed/failed/killed (see crates/db/migrations/20251127100000_execution_runs_and_commit_support.sql). With no migration to allow the new value, these inserts will fail with a CHECK constraint error, so create_task_attempt/create_task_and_start will 500 before a process is created. Update the schema or use an existing status before inserting.

Useful? React with 👍 / 👎.

Adds migration to include 'initializing' in the execution_processes
status CHECK constraint. Required for the early ExecutionProcess
creation pattern that surfaces startup failures to clients.
@namastex888
Copy link
Copy Markdown
Author

@codex review this pr

1 similar comment
@namastex888
Copy link
Copy Markdown
Author

@codex review this pr

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +719 to +723
// Start the actual execution
if let Err(start_error) = self
.start_execution_inner(&task_attempt, &execution_process, &executor_action)
.await
{
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P1 Badge Resume log streaming in start_attempt_with_process

start_attempt_with_process returns immediately after start_execution_inner without running the log normalization and spawn_stream_raw_logs_to_db steps that start_execution performs, so execution processes launched via this new async path (now used by the task and task_attempt create endpoints) never persist executor output to the database or normalized feeds. Attempts started through those routes will run but their logs are dropped, leaving clients with missing history and SSE playback.

Useful? React with 👍 / 👎.

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.

1 participant