[integrity] DIFC Integrity-Filtered Events Report — 2026-03-22 #22253
Closed
Replies: 2 comments 1 reply
-
|
/q add a per user analysis of fitetered events |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
🔧 Pay attention, 007! Q is preparing your gadgets for this discussion comment... |
Beta Was this translation helpful? Give feedback.
-
|
This discussion has been marked as outdated by Daily DIFC Integrity-Filtered Events Analyzer. A newer discussion is available at Discussion #22397. |
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.
-
In the last 7 days, 1,277 DIFC integrity-filtered events were detected across 106 workflow runs spanning 19 distinct workflows. The most frequently filtered tool was
list_issues(726 events, 56.9%), and the dominant filter reason was integrity (99.6% of events). The volume is concentrated on 2026-03-21, which had the highest single-day count with 764 events — more than double the activity of the adjacent days. This spike is explained by the large concentration of Issue Monster, Auto-Triage Issues, AI Moderator, Sub-Issue Closer, and Dev workflow runs on that day.The DIFC integrity system is being exercised heavily and correctly: automated workflows (github-actions[bot], Copilot agents) routinely produce issues with
none:allintegrity tags, and the system is faithfully preventing those issues from being read or processed by other workflows that requireapprovedintegrity. The high per-run event counts for Auto-Triage Issues (avg ~57/run) and Sub-Issue Closer (126 events in one run) indicate that these workflows scan lists of issues that are largely composed of unapproved content, triggering high-volume filtering.Key Metrics
integrity(99.6%)list_issues(726 events)📈 Events Over Time
Activity across the 3-day window is consistent, with 2026-03-21 as the peak day (764 events). March 22 shows a lower count (246) because the analysis window captured only a partial day. The consistent daily pattern reflects the scheduled nature of the dominant workflows (Issue Monster runs every ~30 min, Auto-Triage every few hours).
🔧 Top Filtered Tools
list_issues(726) andissue_read(392) together account for 87% of all filtered events. This reflects two patterns: (1) bulk-scan workflows (Auto-Triage, Sub-Issue Closer, AI Moderator, Dev) callinglist_issuesand hitting many unapproved-integrity issues in the results, and (2) Issue Monster callingissue_readfor specific candidate issues that are blocked.search_issues(122 events) is the third-highest, driven by AI Moderator and Workflow Health Manager.search_pull_requests(11 events) comes from PR Triage Agent and Smoke Codex.🏷️ Filter Reasons and Tags
Nearly all filtering (99.6%) is integrity-based. The
none:alltag dominates, meaning affected resources have no integrity approval at all — consistent with automatically-created or externally-submitted issues and PRs. Theunapproved:alltag (12 events) appears on a small number of resources that have been explicitly flagged as unapproved. Five secrecy-filtered events (privatetag) were observed from Workflow Health Manager and Contribution Check, wheresearch_issuesreturned private repository data that the agent is not authorized to access.🗂️ Events by Workflow
📋 Per-Workflow Breakdown
📋 Per-Server Breakdown
All filtered events originate from the
githubMCP server. No other MCP servers generated integrity-filtered events in this period.💡 Tuning Recommendations
Auto-Triage Issues is the largest event producer (~40% of all events). Each run scans issue lists and triggers ~57 filtered events. Consider whether Auto-Triage workflows need to access issues with
none:allintegrity. If triaging bot-created issues is intentional, approve their integrity tags at creation time to reduce noise.Issue Monster runs every ~30 minutes and hits the same recurring integrity-blocked issues repeatedly (e.g., [deps] Update safe patch dependencies (1 update) #21935, [plan] Add frontmatter field name validation with did-you-mean suggestions for common mistakes #22092, Workflow Health Dashboard — 2026-03-21 | Score: 74/100 ↑8 #22108, [ca] Update APM (Agent Package Manager) to v0.8.3 #22118 appear in nearly every run). These are persistent blockers that prevent the workflow from assigning work. Review and either approve the integrity of these long-standing issues or implement a skip-list to avoid repeated attempts.
Sub-Issue Closer generated 126 filtered events in a single run — the highest single-run count of any non-Auto-Triage workflow. This indicates it scans large issue lists. If sub-issue management is a regular operation, pre-approving integrity for issues managed by
github-actions[bot]would significantly reduce filtering.AI Moderator is frequently blocked from moderating issues and PRs because the target content has
none:allintegrity. This creates a moderation gap: issues that need review cannot be reviewed. Consider implementing an integrity approval step earlier in the issue/PR lifecycle (e.g., at creation) to enable the AI Moderator to function.5 secrecy-filtered events (
privatetag) appeared in Contribution Check and Workflow Health Manager. These workflows are searching across scopes that include private repositories. Review whether thesearch_issuesscope should be limited to public repositories only, or grant appropriate secrecy access if private repo searches are intentional.The
unapproved:alltag (12 events) appears primarily on contributor PRs (e.g., from external contributors likedsyme,mhavelock). This is expected behavior — external contributions require explicit approval before workflows can process them. No tuning needed here; the system is working as designed.Generated by the Daily Integrity Analysis workflow
Analysis window: Last 7 days (2026-03-20 to 2026-03-22) | Repository: github/gh-aw
Run: §23399212460
Beta Was this translation helpful? Give feedback.
All reactions