suyashj1231 opened a new pull request, #5607:
URL: https://github.com/apache/texera/pull/5607

   ### What changes were proposed in this PR?
   
   #4177 introduced `LakeFSExceptionHandler.withLakeFSErrorHandling`, but only 
the multipart-upload and dataset-version paths used it. The remaining LakeFS 
call sites in `DatasetResource` either leaked raw 
`io.lakefs.clients.sdk.ApiException` to Dropwizard (an opaque 500 for the 
frontend) or caught `Exception` and rewrapped it as a generic 500, discarding 
the real LakeFS status code (401/403/404/409/...).
   
   ```
   Before:  LakeFS 404  ->  raw ApiException / catch(Exception)  ->  500 
"Failed to ..."
   After:   LakeFS 404  ->  withLakeFSErrorHandling              ->  404 "Error 
while deleting file 'a.csv' ...: LakeFS resource not found. ..."
   ```
   
   Changes:
   
   | Change | Where |
   | --- | --- |
   | New overload `withLakeFSErrorHandling(operation: String)(call)` that 
prefixes the user-visible message with the failed operation | 
`LakeFSExceptionHandler.scala` |
   | 8 bare LakeFS calls now wrapped (size lookup, version listing, zip 
download, presigned URLs, cover image) | `DatasetResource.scala` |
   | 5 `catch Exception -> generic 500` blocks now use the handler; 
compensation logic (DB rollback on failed repo init, multipart abort) is 
preserved, and the abort-on-failure cleanup no longer masks the original error 
| `DatasetResource.scala` |
   
   Intentionally unchanged: best-effort cleanup sites that deliberately swallow 
errors, the per-dataset skip in `listDatasets`, and the `FileService` startup 
health check (failing fast at boot is correct there).
   
   ### Any related issues, documentation, discussions?
   
   Closes #4176
   
   ### How was this PR tested?
   
   New `LakeFSExceptionHandlerSpec` (7 unit cases): status-code mapping 
(400/401/403/404/409/4xx/5xx/unknown), operation context included in the 
frontend-visible message, success passthrough, and non-LakeFS exceptions 
propagating untouched.
   
   New integration case in `DatasetResourceSpec`: deleting a dataset whose 
LakeFS repository does not exist now yields `NotFoundException` (404) instead 
of a generic 500.
   
   ```
   sbt "FileService/testOnly 
org.apache.texera.service.util.LakeFSExceptionHandlerSpec"
   # Tests: succeeded 7, failed 0
   sbt "FileService/testOnly 
org.apache.texera.service.resource.DatasetResourceSpec"
   # Tests: succeeded 94, failed 0  (Testcontainers: LakeFS 1.51 + MinIO + 
Postgres)
   ```
   
   `sbt FileService/scalafixAll` and `sbt FileService/scalafmtAll` produce no 
further diff.
   
   ### Was this PR authored or co-authored using generative AI tooling?
   
   Yes, partially. I (Suyash Jain) worked on this PR together with Claude Code 
as a pair-programming assistant. I reviewed the final diff and ran the unit and 
Testcontainers-based integration suites locally before opening the PR.
   
   Generated-by: Claude Code (Claude Opus 4.7)


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