Skip to content

feat: configurable allowed_labels + brand rate-limit label with bot.name - #1

Merged
sudsali merged 1 commit into
mainfrom
feat/configurable-allowed-labels-and-ratelimit-brand
Jul 10, 2026
Merged

feat: configurable allowed_labels + brand rate-limit label with bot.name#1
sudsali merged 1 commit into
mainfrom
feat/configurable-allowed-labels-and-ratelimit-brand

Conversation

@sudsali

@sudsali sudsali commented Jul 9, 2026

Copy link
Copy Markdown
Owner

Summary

Two small engine changes surfaced while migrating deequ / python-deequ / dqdl onto the shared engine.

1. Configurable allowed_labels

The issue-triage label allowlist was a hardcoded set {bug, enhancement, question, documentation, help-wanted}, so adopters couldn't apply repo-specific labels (python-deequ's python, dqdl's java) — the engine dropped them before the Labels API call.

Now resolved from .shadow.yml bot.allowed_labels (a list) or BOT_ALLOWED_LABELS (comma-separated env), each entry scrubbed like any posted label. Empty / all-garbage config falls back to the original default set, so existing deployments are unchanged.

2. Brand the rate-limit label with bot.name

The rate-limit escalation label was a hardcoded shadow:rate-limited literal that ignored bot.name. Now f"{bot_name}:rate-limited", so a repo running bot.name: deequ-bot gets deequ-bot:rate-limited.

Critically, this label is now appended in act() after the allowed_labels filter (the same way escalate_label is), scoped to reason == "rate_limited". Previously it was written into the artifact but silently dropped by the allowlist filter, so it never reached GitHub or Slack — an engine-generated label must not be subject to the model-proposed-label allowlist.

Tests

tests/unit/test_allowed_labels.py — 11 cases, including an end-to-end act() test that writes a rate_limited artifact, mocks the GitHub/Slack clients, and asserts the branded label actually reaches add_labels (fails without the fix). Full suite: 538 pass.

Compatibility

No behavior change for existing adopters: allowed_labels defaults to the prior hardcoded set, and the rate-limit label only changes from shadow: to <bot.name>: (identical for the default bot.name: shadow).

Two engine changes surfaced by the deequ/python-deequ/dqdl migrations:

1. allowed_labels was a hardcoded set, so issue-triage dropped repo-specific
   labels (python-deequ's 'python', dqdl's 'java'). Now reads from .shadow.yml
   bot.allowed_labels (list) or BOT_ALLOWED_LABELS env (comma-separated), each
   entry scrubbed like any posted label. Empty/garbage falls back to the
   original default set, so existing deployments are unchanged.

2. The rate-limit escalation label was a hardcoded 'shadow:rate-limited'
   literal that ignored bot.name. Now branded f'{bot_name}:rate-limited', and
   appended in act() AFTER the allowed_labels filter (like escalate_label) so
   it actually reaches GitHub — an engine-generated label must not be dropped
   by the model-proposed-label allowlist.

Adds tests/unit/test_allowed_labels.py (11 cases incl. an end-to-end act()
test asserting the branded label reaches add_labels) + README updates. Full
suite 538 pass.
@sudsali
sudsali force-pushed the feat/configurable-allowed-labels-and-ratelimit-brand branch from 0973529 to c6a9295 Compare July 10, 2026 15:31
@sudsali
sudsali merged commit ed31ed7 into main Jul 10, 2026
3 checks passed
@sudsali
sudsali deleted the feat/configurable-allowed-labels-and-ratelimit-brand branch July 10, 2026 15:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant