What happened?
ImageTaskCodegen.parsePython's image-to-image branch hands provider-supplied values to _url_to_data_url without checking their type, and indexes images without checking it is a list. Verified by running the generated parser:
| Response body |
Result |
{"images": [{"url": null}]} |
_url_to_data_url called with None |
{"images": [{"url": 7}]} |
_url_to_data_url called with an int |
{"images": {"a": 1}} |
raises KeyError |
{"data": [{"url": null}]} |
_url_to_data_url called with None |
Three gaps:
images[0]["url"] is unvalidated (lines 137-138). A non-string reaches _fetch_remote_url and urlparse.images is indexed without an isinstance(images, list) check (line 137). A dict body raises KeyError, which _parse_response catches, so it degrades by exception rather than cleanly.data[0]["url"] is unvalidated (lines 148-149), the same gap as 1.
The inconsistency is the clearest sign this is unintended: the output branch at line 133 and the outputs branch below it both already guard with isinstance(url, str) and url.startswith("http"). The images and data branches in the same function do not.
These do not abort the run and _parse_response catches KeyError, IndexError and TypeError, and the row loop catches the rest per row, so the effect is a wasted fetch attempt or a cell holding the raw body instead of an image.
This is the remainder of the same defect class as #8869 and #8870. #8885 was deliberately scoped to b64_json only, leaving these for a separate change.
How to reproduce?
Run the operator with image-to-image against a provider that returns a 200 whose images[0].url or data[0].url is null or numeric, or whose images is an object rather than an array.
Version/Branch
1.4.0-incubating-SNAPSHOT (main)
Commit Hash (Optional)
No response
What browsers are you seeing the problem on?
No response
Relevant log output
Visitar URL original
What happened?
ImageTaskCodegen.parsePython'simage-to-imagebranch hands provider-supplied values to_url_to_data_urlwithout checking their type, and indexesimageswithout checking it is a list. Verified by running the generated parser:{"images": [{"url": null}]}_url_to_data_urlcalled withNone{"images": [{"url": 7}]}_url_to_data_urlcalled with an int{"images": {"a": 1}}KeyError{"data": [{"url": null}]}_url_to_data_urlcalled withNoneThree gaps:
images[0]["url"]is unvalidated (lines 137-138). A non-string reaches_fetch_remote_urlandurlparse.imagesis indexed without anisinstance(images, list)check (line 137). A dict body raisesKeyError, which_parse_responsecatches, so it degrades by exception rather than cleanly.data[0]["url"]is unvalidated (lines 148-149), the same gap as 1.The inconsistency is the clearest sign this is unintended: the
outputbranch at line 133 and theoutputsbranch below it both already guard withisinstance(url, str) and url.startswith("http"). Theimagesanddatabranches in the same function do not.These do not abort the run and
_parse_responsecatchesKeyError,IndexErrorandTypeError, and the row loop catches the rest per row, so the effect is a wasted fetch attempt or a cell holding the raw body instead of an image.This is the remainder of the same defect class as #8869 and #8870. #8885 was deliberately scoped to
b64_jsononly, leaving these for a separate change.How to reproduce?
Run the operator with
image-to-imageagainst a provider that returns a 200 whoseimages[0].urlordata[0].urlis null or numeric, or whoseimagesis an object rather than an array.Version/Branch
1.4.0-incubating-SNAPSHOT (main)
Commit Hash (Optional)
No response
What browsers are you seeing the problem on?
No response
Relevant log output