Skip to content

dashboard/app: moderate and report AI patches to the mailing lists#7047

Open
a-nogikh wants to merge 15 commits intogoogle:masterfrom
a-nogikh:features/ai-patches-integration
Open

dashboard/app: moderate and report AI patches to the mailing lists#7047
a-nogikh wants to merge 15 commits intogoogle:masterfrom
a-nogikh:features/ai-patches-integration

Conversation

@a-nogikh
Copy link
Copy Markdown
Collaborator

@a-nogikh a-nogikh commented Apr 8, 2026

Summary for the reviewer:


Architecture & Design

  • External Reporting: The reporting logic is isolated from the dashboard. They interact solely via the dashapi API (e.g., PollExternalReport, AIConfirmReport, AIReportCommand).
  • Communication Model: We send patches from syzbot@kernel.org and receive replies by polling the Lore Git archive for syzbot@lists.linux.dev (avoiding the need for a listening SMTP server).

Once we pilot this integration here, we may later switch whole of syzbot to it.

Components Added:

  1. Lore Relay (pkg/lore-relay): A service that bridges Dashboard and Lore. It polls Dashboard for outgoing reports and polls Lore for incoming replies. It will be hosted on a GKE cluster (see syz-agent/lore-relay).
  2. Lore Poller (pkg/email/lore): Fetches and parses emails from a Git-based Lore archive.
  3. Email Sender (pkg/email/sender): Library for sending emails over SMTP.
  4. Dashboard API & UI: New endpoints for reporting flow management and UI for review comments.

Success Workflow

  1. Job Trigger: Dashboard creates an AI patch job.
  2. Execution: AI agent generates a patch and uploads it.
  3. Polling: lore-relay polls Dashboard for pending reports (PollExternalReport).
  4. Sending: lore-relay sends the patch email via pkg/email/sender.
  5. Confirmation: lore-relay notifies Dashboard of publication (AIConfirmReport).

We can configure multiple reporting stages, i.e.

  1. The patch gets reported to the moderation mailing list as [PATCH RFC] Fix ABCD.
  2. Users review and eventually post #syz upstream.
  3. The patch is sent to the public mailing lists.

What is NOT implemented yet

  1. The series collects user review comments under the reported patches, but there's no pkg/aflow workflow to react to them yet. The PR is already too big for that.
  2. We might consider adding white-lists of users (at least domains) from which we'd accept review comments and upstream commands. Also, we want to verify DKIM for the replies before reacting to them.
  3. Since we don't react to review comments yet, the system does not keep track of patch versions. In the end we should first send [PATCH RFC] Fix ABCD, then [PATCH RFC v2] Fix ABCD, etc.
  4. Also, since we don't react to review comments, we don't keep change history. But in the next PRs we should track it and, at the bottom of each subsequent patch, include a history of its previous versions with links to them.
  5. We want some guardlines w.r.t. the number of emails we send daily. Just in case.

a-nogikh added 15 commits April 8, 2026 14:25
Just a string sort becomes problematic once we go above 10 migrations.
Explicitly parse the file names and sort by the full numbers at the
beginning.
The API will let us implement external AI job reporters.
Several configurable stages are supported.
It's more reiable to update the job field inside the transaction than to
separate querying and saving it.
Unify web interface and dashapi AI commands journaling.
For commands submitted via dashapi, use Journal to ensure idempotency -
if we have already processed a command with the same ExtID, do not
actually do it.
It was necessary to save memory, but now it complicates email archive
listetning implementations.

Reset Body and Patch explicitly where it's really needed.
The implementation will be used for polling replies under the syzbot
LKML archive.

Instead of relying on persistent storage for root message id tracking,
use an in-memory graph of the messages. That is simple and will work for
a very long time.

Also, avoid storing "last processed" cursors - instead, take all last
day's messages on start. If the processing API is idempotent, that is
also a simple and reliable solution.
Use the newly created pkg/email/lore.Poller when receiving user commands
in syz-cluster.
It will be used in AI job result moderation.
Move the code from syz-cluster/pkg/emailclient so that it can be reused
more easily.
The new package will contain the functionality that integrates AI job
reporting API with Lore.

For now, add initial templates for the emails we'll be sending.
The component represents a lore integration of AI job result reporting.
It polls dashapi and the lore archive at the same time.

Add various integration tests.
We'll reuse this folder for other AI-related components.
Move the code that resolved prefixed keys from syz-agent to make it
reusable in other components.
Load the config and run the pkg/lore-relay functionality.
Host on GKE.
We'll use these later to regenerate the new patch versions.
@a-nogikh a-nogikh added the AI patching Feature requests and bugs related to AI-based kernel bug fix generation. label Apr 8, 2026
@a-nogikh a-nogikh requested a review from tarasmadan April 8, 2026 14:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AI patching Feature requests and bugs related to AI-based kernel bug fix generation.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant