youtube videos list: request all non-owner parts by default (+ --parts flag)#871
Open
coeur-de-loup wants to merge 1 commit into
Open
youtube videos list: request all non-owner parts by default (+ --parts flag)#871coeur-de-loup wants to merge 1 commit into
coeur-de-loup wants to merge 1 commit into
Conversation
Extend 'yt videos list' so it fetches every videos.list part readable for arbitrary (non-owned) videos — snippet, contentDetails, statistics, status, topicDetails, recordingDetails, liveStreamingDetails, player, localizations — instead of only the previous 3 (snippet,contentDetails,statistics). A new --parts flag narrows the set when desired; the default is the full non-owner list. Owner-only parts (fileDetails/processingDetails/suggestions) are deliberately excluded — the API returns them only for the account's own uploads. The Google SDK omits parts with no data for a given video (e.g. liveStreamingDetails on a non-live video), so the broad request tolerates per-video partial responses without erroring. Tests assert the full part set is requested by default, --parts overrides it, non-core part fields (status.privacyStatus, topicDetails, all thumbnail sizes, liveStreamingDetails) survive in --json output, and a video missing optional parts still serializes cleanly.
Contributor
|
Codex review: needs real behavior proof before merge. Reviewed June 22, 2026, 9:32 PM ET / 01:32 UTC. Summary Reproducibility: not applicable. this is a feature/default-change PR rather than a bug report. Source inspection confirms the omitted-flag behavior would change on the PR branch. Review metrics: 2 noteworthy metrics.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Keep the old three-part default unless maintainers explicitly choose broad-by-default; add documented opt-in broad selection, regenerated command docs, and redacted real command output proof before merge. Do we have a high-confidence way to reproduce the issue? Not applicable: this is a feature/default-change PR rather than a bug report. Source inspection confirms the omitted-flag behavior would change on the PR branch. Is this the best way to solve the issue? No: the implementation is focused, but broad-by-default changes existing output and quota behavior without maintainer approval. The safer path is opt-in broad selection or an explicit maintainer decision plus docs and real proof. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against fc13b4147e20. Label changesLabel changes:
Label justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
clawsweeper
Bot
added
rating: 🧂 unranked krab
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.
What
gog youtube videos listcurrently requests only three parts —snippet,contentDetails,statistics— so--jsonsilently drops everything else the API returns for a non-owned video.This makes the default request broad: every part readable for any non-owned video —
snippet, contentDetails, statistics, status, topicDetails, recordingDetails, liveStreamingDetails, player, localizations— and adds a--partsflag to narrow it back down (e.g.--parts snippet,statistics).Why
Tools that archive video metadata want lossless capture by default rather than having to enumerate parts. Default-broad + opt-in-narrow matches what read-only consumers generally expect.
Details
fileDetails,processingDetails,suggestions) are deliberately excluded from the default — the API 403s on them for videos the authenticated user doesn't own. They remain requestable via explicit--partsif you target your own uploads.liveStreamingDetailson a non-live video), so the broad request tolerates per-video partial responses without erroring.--parts snippet,contentDetails,statisticsfor the previous minimal behavior.Tests
Adds coverage for: the default requests exactly the nine non-owner parts (never the three owner-only ones);
--partsoverride narrows (incl. whitespace trimming); non-core fields (status.privacyStatus,topicDetails, all thumbnail sizes,liveStreamingDetails) survive into--json; and a video missing optional parts still serializes cleanly.🤖 Generated with Claude Code