microsoft / microsoft/winget-pkgs

[Task]: wingetbot worker — URL/domain 403 class learnings

Open
#411,154 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Area-Validation-Pipeline Issue-Task
Dominant language
No language data
Stars
11.1k
Forks
9.7k
Avg merge
1h 32m
Merged PRs (30d)
616

Description

### Description

Per-class learning tracker for the **wingetbot auto-update PR triage worker** (#411124). Capture evidence and heuristics for the **URL / domain reachability (403 Forbidden)** class here.

**Labels:** `Validation-Forbidden-URL-Error`, `Validation-Domain`, `Validate-Domain-Installer`, `Validation-Agreement-Domain`

### Current disposition (from the 2026-08-01 pilot)

**Diagnose + route → waiver.** A URL 403s the validation service (WAF/geo/UA) but is fine for real users. Ties to the waiver discussion in #408472.

### Learnings so far

- Examples #410681 (`pos-api.coupang.com`) and #410284 (`downloads.npass.app`): **a HEAD from a normal client returned 200 for both**, while the validation service got 403 → the block is service-specific, not a broken URL.
- **Reliable, cheap signal:** `service-got-403` + `normal HEAD = 200` ⇒ **recommend a moderator waiver**, do **not** tell anyone the URL is broken. Distinct from a genuine 404 (dead URL) like #411061's `ReleaseNotesUrl`, where removing the optional field is the fix.
- `Validation-Domain` already escalates to humans by design (canned reply + ICM/moderator assignment) — the worker must complement, not fight, that flow.

### Open questions / learnings to capture

- [ ] Distinguish **installer-URL** 403 (blocks validation entirely, needs waiver) from **metadata-URL** 403 (privacy/ToS — lower stakes).
- [ ] Should the worker replicate the validation service's UA to reproduce the 403 precisely, or is HEAD-200 enough evidence?
- [ ] How does this feed the #408472 waiver mechanism — auto-suggest a `.validation` waiver entry for a moderator to approve?

Parent: #411124

_Created with GitHub Copilot assistance._

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the parent worker issue #411124, the waiver discussion in #408472, and the referenced examples #410681, #410284, and #411061. Compare installer-URL and metadata-URL 403 cases, then document the agreed evidence and how the worker should route them; the open questions need resolution before completion can be defined.

Written by the indexing model from the issue text.

Assessment

Domain
documentation
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.