fix(review): let a reward mapping opt into maintainer-authored-issue trust#4422
Merged
Merged
Conversation
…trust gittensor:priority propagation required the PR author to be the linked issue's own author or a GitHub assignee of it, with no relaxation -- unlike bug/feature, which already trust a maintainer-authored issue without formal assignment (trustMaintainerAuthoredIssue). But GitHub silently refuses to assign a contributor lacking push/triage access to the repo, and our issues are almost always maintainer-authored for open pickup, rarely formally assigned to a specific person. That combination meant the reward label could structurally never reach the external contributors it exists to reward, no matter how correctly the rest of the propagation pipeline behaved -- confirmed live on metagraphed PR #4554 (issue #3947 carried both gittensor:bug and gittensor:priority; only bug ever propagated). Adds a new, distinctly-named, opt-in LinkedIssueLabelPropagationMapping flag, trustMaintainerAuthoredIssueForReward, so a repo whose priority label is meant to incentivize open pickup (the maintainer's hand-picking already happened when the issue was labeled, not gated on which contributor later closes it) can extend the SAME maintainer-authored-issue relaxation to its reward mapping, while a repo that wants the strict author-or-assignee bar preserved for its reward label keeps that behavior unchanged by default. Enabled it for gittensor:priority in this repo's own config, matching the enrichment-issue open-pickup policy this label already implements for metagraphed.
Contributor
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
gittensory-ui | 304e88c | Commit Preview URL Branch Preview URL |
Jul 09 2026, 12:46 PM |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4422 +/- ##
=======================================
Coverage 93.98% 93.98%
=======================================
Files 406 406
Lines 36993 37001 +8
Branches 13521 13525 +4
=======================================
+ Hits 34767 34775 +8
Misses 1570 1570
Partials 656 656
🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
gittensor:prioritypropagation required the PR author to be the linked issue's own author or a GitHub assignee of it, with no relaxation available — unlikegittensor:bug/gittensor:feature, which already trust a maintainer-authored issue without requiring formal assignment (trustMaintainerAuthoredIssue). But GitHub silently refuses to assign a contributor lacking push/triage access to the repo (ensurePullRequestAssignee's own doc comment), and our issues are almost always maintainer-authored for open pickup, rarely formally assigned to a specific person. That combination meant the reward label could structurally never reach the external contributors it exists to reward, no matter how correctly the rest of the propagation pipeline behaved.gittensor:bugandgittensor:priority. Onlygittensor:bugever propagated, across two separate evaluations, even after an earlier same-day fix (exclusive/additive composition) had already deployed. Traced viaagent.action.assign's own audit event: the assign action was correctly configured, but even once it runs successfully it only ever assigns the contributor to the PR, never the linked issue — and for a genuinely external, non-collaborator contributor, GitHub would refuse that issue-level assignment anyway.LinkedIssueLabelPropagationMappingflag:trustMaintainerAuthoredIssueForReward. A repo whose priority label is meant to incentivize open pickup (the maintainer's hand-picking already happened when the issue was labeledgittensor:priority, not gated on which contributor later closes it) can extend the SAME maintainer-authored-issue relaxation bug/feature already use to its reward mapping. A repo that wants the strict author-or-assignee bar preserved for its reward label keeps that behavior completely unchanged by default — this is a pure opt-in, not a loosening of the existing check.gittensor:priorityin this repo's own config (.gittensory.yml+ the bundled fallback it must stay byte-synced with), matching the standing "enrichment issues are open-pickup, priority-as-incentive" policy this label already implements for metagraphed.Scope
type(scope): short summaryConventional Commit format.CONTRIBUTING.mdand does not reintroduce GitHub Pages, VitePress,site/, orCNAME.Validation
npm run typechecknpm run manifest:drift-check/npm run docs:drift-check— both clean.npm run ui:openapi(regenerated) /npm run ui:openapi:check/npm run ui:openapi:settings-parity— all clean.npx vitest run test/unit/linked-issue-label-propagation.test.ts test/unit/linked-issue-label-propagation-engine.test.ts test/unit/linked-issue-label-propagation-fetch.test.ts test/contract/engine-parity.test.ts— 71/71 pass, including new tests for both the normalizer (parse/warn/default for the new flag, mirrored in both the main and engine-package copies) and the actual fetch/ownership behavior (a regression test reproducing the exact PR fix(db): renumber impact-map-query-cache migration to resolve 0131 collision #4554/issue fix(review): keep missing required CI pending #3947 shape: both labels now propagate).npx vitest run test/unit/queue.test.ts test/unit/pr-type-label.test.ts test/unit/pr-type-label-engine.test.ts— 828/828 pass (full integration coverage of the changed config, unaffected since the existing test's PR/issue author match via the direct-ownership path, not the new relaxation).If any required check was skipped, explain why:
npm run test:cigate is left to CI per the repo's own established practice for this size of change.Safety
RepositorySettingsSchemaand the OpenAPI spec regenerated + parity-checked.UI Evidencesection. — N/A, no UI changes..gittensory.ymlexample templates document the new flag alongside the code fix.Notes
agent.action.assign's own audit trail on the exact reported PR, then confirmed the deeper structural gap (GitHub's own assignment-permission model) via a dedicated background investigation before choosing this fix over a narrower reordering-only patch, which would only have helped the minority of contributors GitHub happens to permit as assignees.