Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

get_job_logs: run_id with failed_only=false should return all job logs; failed_only should be a consistent modifier

Offen
#2,389 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
64/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
github, go
Bereich
api, backend

Rechercherichtung

Beginne bei der Implementierung von get_job_logs und verfolge, wie job_id, run_id und failed_only validiert werden, einschließlich der bestehenden Suche nach Job-Metadaten. Füge eine gezielte Abdeckung für die im Issue genannten Parameterkombinationen hinzu und überprüfe, dass bestehende erfolgreiche Aufrufe unverändert bleiben, während die vorgeschlagenen Anfragen auf Run-Ebene und für fehlgeschlagene Jobs funktionieren.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

This came out of an analysis of github MCP server errors encountered in my past sessions across 5000 sessions.

What happened

An agent trying to retrieve all job logs for a workflow run passed:

{"owner":"danmoseley","repo":"pr-dashboard","run_id":22854416647,"return_content":true,"tail_lines":500,"failed_only":false}

And got:

job_id is required when failed_only is false

This happened 6 times across 5 sessions. The agent's intent was clear and reasonable: get all logs for this run, not just failed ones. It even explicitly set failed_only=false to signal that — and got an error.

Why the current design is confusing for agents

failed_only is used as a mode switch rather than a modifier:

  • run_id without failed_only=true always errors, even though "get logs for this run" is a valid request
  • failed_only has no effect when job_id is provided — it is silently ignored
Proposed behavior

failed_only should be a consistent modifier on whichever ID is provided:

Parameters Result Proposed
job_id + failed_only=false (or not passed) logs for that job already allowed
job_id + failed_only=true logs for that job if it failed; isError:true with status if it succeeded error -> allowed
run_id + failed_only=false (or not passed) logs for all jobs in the run already allowed
run_id + failed_only=true logs for failed jobs only error -> allowed
both job_id and run_id isError:true — provide one or the other, not both error
neither isError:true — one of job_id or run_id must be provided error

The job_id + failed_only=true case requires checking the job's conclusion before fetching logs, but the tool already fetches job metadata to get the log URL so this is a small addition.

Breaking change note

No changes to existing successful calls. This only makes certain calls that are failing begin to work.

Vorherrschende Sprache
Go
Sterne
33.1k
Forks
5k
Ø Merge
2 T. 3 Std.
Gemergte PRs (30 T.)
18

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus github/github-mcp-server

Alle Issues in github/github-mcp-server

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.