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]