aglinxinyuan opened a new issue, #7272:
URL: https://github.com/apache/texera/issues/7272

   ### Task Summary
   
   `LakeFSStorageClient` (83 missed, 37.9%) is the largest unclaimed coverage 
gap in the repo. The existing `LakeFSStorageClientSpec` only exercises 
`parsePhysicalAddress`; everything else needs a lakeFS server, and the only 
harness for that is `LakeFSStorageClientMtimeSpec`, which is 
Docker/testcontainers-based.
   
   Most of it is reachable without a container. `StorageConfig.lakefsEndpoint` 
is a `var` — the comment above it says it exists so tests can repoint it — so a 
JDK `com.sun.net.httpserver` stub on `127.0.0.1:0` can stand in for the server 
with no new dependency.
   
   Several behaviours are in fact **only** observable against a stub:
   
   - `fetchAllPages`' cursor threading and page accumulation — `PageSize` is 
1000, so a live server would need 1001 objects to produce a second page
   - `retrieveVersionsOfRepository`'s descending sort — lakeFS already returns 
commits newest-first, so against a live server the sort is a no-op
   - `completePresignedMultipartUploads`' part ordering, checkable on the 
serialized request body
   - "validation rejected this without issuing a request", which a live server 
cannot distinguish from a request it rejected itself
   
   Two constraints any such spec has to respect:
   
   - **`apiClient` is a `private lazy val`**, as are the seven `*Api` vals 
derived from it, so the endpoint is captured once per JVM on first force. 
`MtimeSpec` repoints it at a container. The two suites therefore cannot share a 
JVM once the non-container spec starts forcing the client. 
`common/workflow-core/build.sbt` already solves this: suites annotated 
`@NonParallelTest` each get their own forked `Tests.Group`. Tagging both is the 
durable fix.
   - **Do not "cover" anything by letting a connection fail and asserting the 
resulting `ApiException`.** That asserts the absence of a service and inverts 
the moment CI gains a lakeFS container.
   
   Also worth noting for whoever picks this up: `removeFileFromRepo` and 
`retrieveFileContent` have no callers anywhere in the repo, 
`withCreateVersion`'s only caller is a file-service test, and `stagingApi` is 
referenced nowhere. Those want deleting, not testing.
   
   ### Task Type
   
   - [ ] Refactor / Cleanup
   - [ ] DevOps / Deployment / CI
   - [x] Testing / QA
   - [ ] Documentation
   - [ ] Performance
   - [ ] Other
   


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