[integrity] DIFC Integrity-Filtered Events Report — 2026-04-01 #23945
Closed
Replies: 1 comment
-
|
This discussion has been marked as outdated by Daily DIFC Integrity-Filtered Events Analyzer. A newer discussion is available at Discussion #24169. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Executive Summary
In the last 7 days, 439 DIFC integrity-filtered events were detected across 13 workflow runs (from 49 total flagged runs). The most frequently filtered tool was
list_issues(341 events, 78%), and the dominant filter reason was uniformlyintegrity— all events were blocked because the resource had integrity levelnoneorunapproved, which is below the agent's requiredapprovedthreshold.The filtering volume is heavily driven by two workflows: Auto-Triage Issues (235 events, 54%) and Issue Triage Agent (80 events, 18%). The pattern is consistent: agents attempt to triage or process community-filed issues that carry
none:allintegrity tags, are blocked, and loop — resulting in repeated filtering across consecutive scheduled runs. Issues #23725 and #23726 appear in nearly every Issue Monster / Auto-Triage run, suggesting a persistent unresolved backlog of community issues that the agents cannot access.Key Metrics
integrity(100%)none:all(100%),unapproved:all(22%)📈 Events Over Time
The volume is rising day-over-day: 174 events on March 31 grew to 265 on April 1 — a 52% single-day increase. This is consistent with multiple scheduled workflows (Auto-Triage, Sub-Issue Closer, Issue Triage Agent) all triggering on the same pool of unresolvable community issues. Without resolution, this count will continue to compound daily.
🔧 Top Filtered Tools
list_issuesdominates at 341 events (78%), followed bysearch_issuesat 85 (19%). These are the primary discovery tools used by triage and sub-issue workflows to find actionable work items. The filtering occurs because the workflows discover community issues withnone:allintegrity and then attempt to read them — every matching issue in a query generates a filtered event.issue_read(7),pull_request_read(4), andlist_pull_requests(1) account for the remainder, representing direct access attempts on specific low-integrity resources.🏷️ Filter Reasons and Tags
All 439 events carry the
none:allintegrity tag — these are resources with no established integrity provenance. A subset of 97 events (22%) additionally carryunapproved:all, indicating resources that were explicitly reviewed and not approved (contributor-associationNONE). No secrecy filtering was detected. The filtered resource types are overwhelmingly issues (430), with a small number of pull_requests (5) and commits (1), reflecting the workflows' primary focus on issue triage.📋 Per-Workflow Breakdown
📋 Per-Server Breakdown
All filtering originates from the
githubMCP server — no other servers generated filtered events during this period.👤 Per-User Breakdown (Top 15)
🔍 Per-User Analysis
The filtering is driven entirely by human contributors (author_association
NONEorCONTRIBUTOR) — there is no bot or automation account among the top filtered users.szabta89leads with 55 events, followed bydanielmeppiel(40) andmnkiefer(28). These are not necessarily users behaving badly; they are the authors of issues that the triage/sub-issue workflows are repeatedly trying — and failing — to read. The high counts reflect the fact that each scheduled run re-encounters the same unresolved community issues. Issues bykbreit-insight(#23725) andcamposbrunocampos(#23726) appear in nearly every Issue Monster / Auto-Triage run.💡 Tuning Recommendations
Address the persistent issue backlog (highest impact): Issues create-code-scanning-alert safe-output doesn't seem to work as it should #23725 and assign_to_agent: allow multiple assignments to same issue when pull_request_repo differs #23726 are responsible for a large share of repeated filtering events across ~20+ Issue Monster runs. Either approve these issues (grant
approvedintegrity) or close/label them to remove them from the triage queue. This single action could eliminate the majority of recurring filter noise.Add integrity-awareness to Auto-Triage Issues and Sub-Issue Closer: These workflows should include a pre-agent step that filters the issue list to only
approved-integrity resources before passing them to the agent. Use theactivation.outputs.filtered_issuespattern or a pre-stepgh apiquery with integrity tag filtering to avoid the agent even attempting to read low-integrity issues.Review contributor onboarding for high-volume authors: Users
szabta89(55 events) anddanielmeppiel(40 events) are repeatedly creating content that triggers integrity filtering. Consider adding a welcome/triage bot comment on first-time contributor issues to guide them through the approval process, or lower the required approval threshold for well-formed issues.Investigate the rising trend: The 52% day-over-day increase (174 → 265 events) suggests that the pool of unresolvable community issues is growing faster than approvals. Schedule a weekly integrity review or automate approval for issues meeting quality criteria (e.g., issues from CONTRIBUTOR-level or higher associations).
Smoke test filtering (Smoke Claude, Smoke Copilot): These runs each triggered 1–2 filtered events. Verify that smoke test workflows are not inadvertently targeting real low-integrity resources — they should use synthetic or pre-approved test fixtures.
Go Fan / Architecture Diagram Generator / Code Simplifier: These generated single filtered events against external commits (
cli/go-gh@55692c6b) and community PRs. These are expected DIFC behaviors and do not require tuning, but confirming that the agents gracefully handle the filtered response (e.g., skip instead of fail) would improve resilience.References:
Beta Was this translation helpful? Give feedback.
All reactions