PG1204 opened a new pull request, #8885: URL: https://github.com/apache/texera/pull/8885
### What changes were proposed in this PR? `ImageTaskCodegen.parsePython`'s `image-to-image` branch built a data URL from the provider's `b64_json` without checking it, so a malformed but valid-JSON 200 put an unrenderable value in the result column, a null field became the literal `data:image/png;base64,None`, with nothing to indicate why the image was blank. `b64_json` must now be a non-empty string; anything else falls through to `json.dumps(body)`, which is what the branch already did for unrecognised shapes. Scoped deliberately to `b64_json`, matching the issue. The sibling `url` lookups in the same branch have a comparable gap and are left for a separate issue. Not addressed: a `b64_json` that is a string but not valid base64 still yields an unrenderable data URL. Detecting that means decoding the value on every row, and corrupt-but-well-formed base64 would pass regardless, so the browser's rejection is unchanged either way. Same reasoning as #8872. ### Any related issues? Closes #8870 ### How was this PR tested? Written test-first: a test asserting the string guard was added to `ImageTaskCodegenSpec` and fails against the current parse. The suite is at 155 tests, `PythonCodeRawInvalidTextSpec` py-compiles all 117 operators, and `scalafmtCheck` and `scalafix --check` are clean. The generated parser was also run directly: a null or numeric `b64_json` now returns the serialized body, and a valid base64 payload still produces the same data URL as before. ### Was this PR authored or co-authored using generative AI tooling? Yes, this PR was co-authored with Claude in compliance with ASF policy. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
