Refuse a frame the renderer cannot draw, and honour two config keys - #214
Merged
Conversation
A thumbnail is an HTML page photographed by headless Chrome, so the frame is an <img>. A file the browser cannot decode was never an error: the page rendered anyway, the caption box and the logo landed on bg_color, and the command exited 0 with a path to a blank card carrying a 15px broken-image glyph in the corner. On a dark template that is a black rectangle nobody can tell apart from a picture that worked, and every caller downstream stored it as a finished thumbnail. A missing frame was worse, because it also moved the box to the no-photo height. Both are refused now, in the words of what happened, while the answer is still a message about one picture. The file:// URIs are built with as_uri() rather than an f-string: a '#' or a '?' anywhere in the path was a fragment or a query to the browser, so the image silently dropped and the card rendered as bg_color the same way. photo_object_position was asked of the model, exposed in the template editor and then never read; the CSS hardcoded center center. line1_nowrap shipped in the defaults and was documented as tunable while the renderer overwrote it unconditionally. Both now do what they say.
|
Warning Review limit reachedNext included review available in 56 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This was referenced Sep 5, 2026
Merged
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
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.
A thumbnail is an HTML page photographed by headless Chrome, so the frame is an
<img>. A file the browser cannot decode was never an error: the page rendered anyway, the caption box and the logo landed onbg_color, andthumbnail-renderexited 0 with a path to a blank card carrying a 15px broken-image glyph in the corner. On a dark template that is a black rectangle nobody can tell apart from a picture that worked, and every caller downstream stored it as a finished thumbnail.A missing frame was worse, because it also moved the text box to the no-photo height, so the failure was visible only as a picture that sat slightly wrong.
Both are refused now, in the words of what happened, while the answer is still a message about one picture rather than a card somebody ships.
Two other things in the same area:
file://URIs for the photo and the logo were built by string concatenation, so a#or a?anywhere in the path was a fragment or a query to the browser and the image silently dropped, rendering asbg_colorthe same way. They usePath.as_uri()now.photo_object_positionwas asked of the model, exposed in the template editor and then never read: the CSS hardcodedcenter center.line1_nowrapshipped in the defaults and was documented as tunable while the renderer overwrote it unconditionally. Both now do what they say.Verification
tests/test_thumbnail_html.pypasses (11), and the CLI was run against a probe matrix:.pngA render with
photo_object_positionandline1_nowrapset was confirmed to pick both up.Context
Found while tracing a podcli-cloud report: a workspace picked one of its own background images for a clip thumbnail and got back three pure black cards. The cloud-side half is fixed separately; this is the engine half, and it is what turns that class of failure from a silent blank card into a job that says why.