Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Consider a generic change-URI metadata/augmentation language (Change API)

Ouverte
  • Quelque chose ne va pas ?
#209 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 2 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
Calme
Stack technique
go
Domaine
backend-api-design

Piste de recherche

Commencez par lire la Change API et les parsers référencés : submitqueue/entity/github/change_id.go, submitqueue/entity/phabricator/change_id.go et submitqueue/extension/changeprovider/github/validate.go. Examinez la PR #197 et la discussion sur core/fakemarker avant de comparer les paramètres de requête, les fragments et un champ Change typé. Le travail est terminé lorsque les questions de portée, de forme et de généralité sont résolues et que la conception choisie est documentée ou implémentée sans compromettre la validation stricte de change-ID.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Context

In #197, the extension fakes inject failures via an ad-hoc sq-fake=<token>
marker embedded in a change URI, parsed by the test-only core/fakemarker
package (Token([]string) / TokenInChanges([]entity.Change)).

Reviewing that PR, @sbalabanov raised two related design questions:

  • Should we build a generic augmentation / metadata language into change
    URIs, usable by these fakes and similar tooling — rather than a
    fake-specific marker convention?
  • The marker lookup (TokenInChanges) arguably belongs on the Change API
    (entity.Change) rather than living in a test-only helper.

This issue captures that idea as a follow-up so #197 can land as-is (the marker
stays test-only there).

Design considerations

A generic change-URI metadata facility would need to reconcile with the
strict provider change-ID parsers, which today reject anything that isn't a
canonical resource identifier:

  • submitqueue/entity/github/change_id.go — requires a full 40-char lowercase
    hex head SHA; a ?key=value query string would not parse.
  • submitqueue/entity/phabricator/change_id.go — fixed phab:// form.
  • submitqueue/extension/changeprovider/github/validate.go — rejects
    unexpected schemes.

Open questions:

  1. Scope — is URI-attached metadata a production capability, or strictly a
    test/example affordance? Putting parsing on entity.Change couples the
    production type to the convention; keeping it in core/fakemarker keeps the
    separation the fakes deliberately maintain ("never production").
  2. Shape — RFC-3986 query params (?k=v) vs. fragment vs. a dedicated
    sidecar field on Change. Query params collide with the strict parsers
    above; a typed field avoids string-encoding entirely.
  3. Generality — a neutral key → value accessor (e.g.
    Change.URIParam(key)) that fakemarker layers sq-fake semantics on top
    of, vs. a richer metadata model.

References

  • PR #197 — fake implementations with error injection
  • Threads: the core/fakemarker.go discussion in #197.

Filed as a follow-up per the #197 review discussion. Not blocking.

Langage dominant
Go
Étoiles
227
Forks
11
Merge moyen
3 j 49 min
PR mergées (30 j)
63

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de uber/submitqueue

Toutes les issues de uber/submitqueue

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.