Xuanwo opened a new issue, #7630:
URL: https://github.com/apache/opendal/issues/7630

   ### Describe the bug
   
   The Hugging Face service can include the full upstream HTML error page in 
OpenDAL error messages. This shows up in CI logs when an expected error path is 
exercised.
   
   Example job: 
https://github.com/apache/opendal/actions/runs/26565670919/job/78260480142
   
   The job passed, but `test_read_not_exist` triggered a `404` from the Hugging 
Face bucket `/resolve/...` endpoint. The response had:
   
   ```text
   content-type: text/html; charset=utf-8
   content-length: 52864
   x-error-code: EntryNotFound
   x-error-message: File not found
   ```
   
   OpenDAL then logged the body as the error message:
   
   ```text
   read failed NotFound ... => <!doctype html>
   <html class="">
   ...
   ```
   
   This pollutes CI logs and may expose more page/session metadata than needed. 
The bearer token is not printed, but dumping an authenticated HTML page into 
public CI logs is still undesirable.
   
   ### Steps to Reproduce
   
   1. Run the Hugging Face bucket HTTP behavior test with logging enabled:
   
   ```bash
   cd core
   RUST_LOG=opendal=trace \
   OPENDAL_TEST=hf \
   OPENDAL_HF_REPO_TYPE=bucket \
   OPENDAL_HF_DOWNLOAD_MODE=http \
   cargo test behavior --features tests,services-hf
   ```
   
   2. Exercise `test_read_not_exist`, which reads a random non-existent path.
   3. Observe that the HF `/resolve/...` 404 HTML response body is included in 
the logged OpenDAL error.
   
   Relevant code path:
   
   - `core/services/hf/src/core.rs`: `HfCore::resolve` buffers non-success 
response bodies and passes them to `parse_error`.
   - `core/services/hf/src/error.rs`: `parse_error` falls back to the entire 
UTF-8 body when JSON parsing fails.
   - `core/layers/logging/src/lib.rs`: `LoggingLayer` prints the resulting 
error message.
   
   ### Expected Behavior
   
   OpenDAL should preserve useful error information without logging full HTML 
or large opaque response bodies.
   
   For Hugging Face responses, error parsing should prefer structured sources 
such as:
   
   1. JSON `{ "error": ... }`
   2. `x-error-message` / `x-error-code` response headers
   3. Small plain-text bodies
   
   For `text/html`, unknown content types, or large bodies, OpenDAL should omit 
or truncate the body and report a compact message such as:
   
   ```text
   File not found
   ```
   
   or:
   
   ```text
   HTTP 404 response body omitted: content-type=text/html; charset=utf-8, 
content-length=52864
   ```
   
   ### Additional Context
   
   The CI job itself was successful; this is a diagnostics and log hygiene 
issue, not a behavior test failure.
   
   The GitHub Action helper `.github/actions/hf-temp-repo/common.js` has a 
similar full-body error pattern for setup/cleanup requests and may deserve the 
same treatment.
   
   It may also be worth asking Hugging Face upstream to return compact 
machine-readable errors for `/resolve/...` failures, or to honor an API-style 
`Accept` header with JSON error responses. OpenDAL should still avoid logging 
full HTML bodies defensively.
   
   ### Are you willing to submit a PR to fix this bug?
   
   - [x] Yes, I would like to submit a PR.
   


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

Reply via email to