codeant-ai-for-open-source[bot] commented on code in PR #41768:
URL: https://github.com/apache/superset/pull/41768#discussion_r3522842618


##########
superset-frontend/src/setup/setupApp.ts:
##########
@@ -41,7 +42,7 @@ function showApiMessage(resp: ClientErrorObject) {
   const severity = resp.severity || 'info';
   $(template)
     .addClass(`alert-${severity}`)
-    .append(resp.message || '')
+    .append(resp.message ? sanitizeHtmlIfNeeded(resp.message) : '')

Review Comment:
   The typing is too narrow for the actual runtime shape.
   
   `ClientErrorObject.message` may be declared as `string | undefined`, but 
`getClientErrorObject` can populate it with a non-string value for 
validation-style responses. In that case, `resp.message` is truthy, yet not 
safe to pass into `sanitizeHtmlIfNeeded`, which expects string-like input.
   
   ### So the issue is:
   - **Type definition says:** `string | undefined`
   - **Runtime can produce:** object-shaped `message` values
   
   ### Recommended fix
   Guard before sanitizing, e.g. only sanitize strings:
   
   ```typescript
   const message =
     typeof resp.message === 'string'
       ? sanitizeHtmlIfNeeded(resp.message)
       : resp.error || '';
   ```
   
   Then:
   
   ```typescript
   .append(message)
   ```
   
   That keeps the HTML sanitization for normal string messages, while avoiding 
crashes on validation/error payloads that return structured data.
   
   So yes: the typing is misleading here, and the safer approach is to handle 
non-string values explicitly in this UI path.



-- 
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]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to