fix: jobs limit

[nickpismenkov]

No description provided.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! 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 resolves an issue where the job concurrency limit was being miscalculated, causing new jobs to be blocked even when sufficient resources were available. The change refines the definition of an 'active' job to only include those actively consuming parallel execution slots, thereby ensuring the max_jobs limit functions as intended and improves job scheduling efficiency.

Highlights

• Job Limit Calculation Refinement: The logic for counting active jobs against the max_jobs limit has been updated to correctly identify only those jobs that are actively consuming execution resources. Previously, Completed and Submitted jobs were incorrectly included in the count, leading to premature MaxJobsExceeded errors.
• New is_parallel_blocking Method: A new method, is_parallel_blocking, was introduced in JobState to precisely determine if a job's current state (Pending, InProgress, or Stuck) should count towards the parallel job limit.
• Comprehensive Test Coverage: Several new asynchronous tests were added to validate the fix, ensuring that sequential routines are not limited by completed jobs, parallel job limits are correctly enforced for active jobs, and completed jobs properly free up execution slots.

Changelog

• src/context/manager.rs
  • Modified the job creation logic to use is_parallel_blocking() for counting jobs against max_jobs.
  • Added new test cases (sequential_routines_unlimited_completed_not_counted, parallel_jobs_limit_enforced_for_active_jobs, completed_jobs_should_free_slots_after_fix) to validate the corrected job limit behavior.
• src/context/state.rs
  • Introduced a new public method is_parallel_blocking() to JobState to check if a job is in a state that consumes a parallel execution slot (Pending, InProgress, or Stuck).

Activity

• No specific activity has been recorded for this pull request yet.

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. ↩

[gemini-code-assist]

Code Review

This pull request correctly addresses an issue with the job limit calculation by introducing a more precise is_parallel_blocking state check, ensuring that completed jobs do not count towards the concurrent job limit. The implementation is sound, and the new tests are comprehensive and effectively validate the fix. I have one suggestion to enhance the clarity of a new test case.