Pad the at-cap fixture plausibly; update first-party deps#395
Merged
Conversation
plexapi v1.3.4 gates its plex.tv XML through an xmlx preflight, which bounds each token at 16 KiB for the shared-servers limits. The at-cap boundary test padded its 10 MB body with a SINGLE comment, so the preflight refused it and the test failed — on the fixture's shape, not on the read cap it exists to pin. The padding is now split across many comments, each well under the token bound, with the block sizing derived from the cap rather than hardcoded so a future cap change cannot silently reintroduce an over-long comment. What the test asserts is unchanged: a body of exactly the cap is read and parsed, because the cap comparison is a strict `>`. Deps: atomicfile v2.3.0 -> v2.4.0, envx v1.2.2 -> v1.3.0, jsonx v1.2.0 -> v1.3.0, plexapi v1.3.2 -> v1.3.4 (xmlx arrives indirectly).
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.
Supersedes Renovate #393, which carried the same dep bumps but failed on
TestSharedUserTokens_AcceptsResponseExactlyAtCap.Why it failed
plexapiv1.3.4 gates its plex.tv XML through anxmlxpreflight, which bounds each token at 16 KiB for the shared-servers limits. The at-cap boundary test padded its 10 MB body with a single comment, so the preflight refused it — the test failed on the fixture's shape, not on the read cap it exists to pin. A cap-sized XML comment is valid XML but not a plausible plex.tv response, so the preflight is right and the fixture was wrong.The padding is now split across many comments, each well under the token bound, with block sizing derived from the cap rather than hardcoded so a future cap change cannot silently reintroduce an over-long comment. What the test asserts is unchanged: a body of exactly the cap is read and parsed, because the cap comparison is a strict
>. Its over-cap sibling is untouched — it sends raw bytes and trips the read cap before any parsing, so it still pinsResponseTooLargeError.Deps
atomicfilev2.3.0 → v2.4.0,envxv1.2.2 → v1.3.0,jsonxv1.2.0 → v1.3.0,plexapiv1.3.2 → v1.3.4 (xmlxarrives indirectly).Testing
go build ./...andgolangci-lint run ./...clean;go test ./...green exceptTestCacheLoadMigrationSaveFailureKeepsLegacy, which fails identically on untouched main in my container because it runs as UID 0 and root bypasses the read-only directory permission the test relies on. CI runs unprivileged, so it passes there.