Add async task multiplexing for concurrent task processing#630
Conversation
There was a problem hiding this comment.
Code Review
This pull request introduces a concurrent task loop (run_task_loop) using an asyncio semaphore to safely process tasks from Redis queues across several agents, alongside a new BufferedTaskHandler to buffer and flush logs per Jira issue. Feedback on these changes highlights a potential deadlock in the task loop's finally block if log flushing raises an exception, which would leak semaphore permits; wrapping the flush in a try-except block is recommended to guarantee release. Additionally, a minor improvement is suggested to simplify trajectory logging by directly passing the pre-formatted message.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
78f1031 to
109be6d
Compare
|
/gemini review |
|
/agentic_review |
There was a problem hiding this comment.
Code Review
This pull request introduces a concurrent task loop using a semaphore to limit concurrency, refactoring several agents to use this loop. It also adds a buffered logging mechanism to group logs by Jira issue and integrates a custom writeable adapter for trajectory logging. The review feedback suggests replacing the logging filter with a custom formatter to prevent potential formatting errors, handling multi-line strings in the trajectory writeable, and resetting the Jira issue context variable before flushing logs to prevent messages from being trapped in the buffer.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces concurrent task processing across several agents (backport, rebase, rebuild, and triage) by replacing sequential Redis popping with a concurrent task loop controlled by a new MAX_CONCURRENT_TASKS environment variable. It also adds a log buffering mechanism (BufferedTaskHandler) controlled by LOG_BUFFER_SIZE to group log outputs per Jira issue. Feedback on the changes highlights a critical concurrency issue in BufferedTaskHandler where the _group_depth counter is shared across threads/tasks. This can lead to race conditions when multiple tasks run concurrently. It is recommended to use a ContextVar to track _group_depth independently per task.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces concurrent task processing and buffered logging across several agents by implementing a shared run_task_loop and a BufferedTaskHandler to buffer logs per Jira issue. Feedback on these changes highlights critical improvements: implementing flush() and close() in BufferedTaskHandler to prevent log loss on shutdown, refactoring run_task_loop for better performance and graceful task cancellation, and aligning the output streams of the logging handlers to ensure consistent destination streams (stdout vs. stderr).
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces a centralized, concurrent task processing loop (run_task_loop) across multiple agents, replacing manual polling loops and adding support for concurrent task execution. It also implements a buffered logging mechanism (BufferedTaskHandler) that groups and flushes logs per Jira issue, utilizing a shared current_jira_issue context variable. Feedback on the changes highlights a potential synchronization issue in BufferedTaskHandler.emit where writing to sys.stdout when no Jira issue is present is done without acquiring the lock, which could lead to interleaved console output.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces a concurrent task loop (run_task_loop) and a buffered logging mechanism (BufferedTaskHandler) to handle task execution and logging more efficiently across various agents. It also standardizes the tracking of the current Jira issue using a shared ContextVar and updates GlobalTrajectoryMiddleware to write logs via a custom writeable adapter. Feedback was provided regarding the cancellation behavior of run_task_loop in ymir/common/base_utils.py. Currently, active tasks are immediately cancelled upon loop cancellation, which could lead to task loss or inconsistent states during a shutdown. It is recommended to allow active tasks to complete gracefully using asyncio.shield before propagating the cancellation.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces concurrent task processing and buffered logging per Jira issue across various agents. It replaces the infinite polling loops in the agents with a centralized, concurrent run_task_loop utility that manages task execution using a semaphore. Additionally, it introduces a BufferedTaskHandler to buffer log lines by Jira issue, flushing them in contiguous batches, and updates the logging format to include the active Jira issue. Feedback on the changes suggests swapping the order of clearing the Jira issue context and flushing task logs in run_task_loop to ensure that any exceptions raised during log flushing are correctly associated with the active Jira issue context.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
TomasKorbar
left a comment
There was a problem hiding this comment.
Please bump the common subpackage version. Otherwise LGTM!
Signed-off-by: Nikola Forró <nforro@redhat.com> Assisted-by: Claude Opus 4.6 via Claude Code
Signed-off-by: Nikola Forró <nforro@redhat.com> Assisted-by: Claude Opus 4.6 via Claude Code
Signed-off-by: Nikola Forró <nforro@redhat.com>
I've added a hook to bump automatically before pushing, unless the version has already changed. |
TomasKorbar
left a comment
There was a problem hiding this comment.
Thanks for the hook. LGTM!
With
MAX_CONCURRENT_TASKS=1(the default), the workflows should behave exactly the same as before. So I think we can deploy this and if there are no regressions, we can try increasing the number and monitor resource usage.This PR also modifies logging:
GlobalTrajectoryMiddlewareoutput now goes through loggers, so it gets prefixed just like regular log messagesLOG_BUFFER_SIZEhigher than zero, log messages associated with the same Jira issue are buffered and output in batches, for better readability when multiple tasks are processed in parallel