mengw15 opened a new issue, #7358:
URL: https://github.com/apache/texera/issues/7358
### Feature Summary
`bin/local-dev.sh` registers the Lakekeeper warehouse with the host
machine's **current LAN IP** as the S3 (MinIO) endpoint — the only address
reachable from both containers (Lakekeeper) and natively-run host services. The
IP is written **once** into the warehouse's storage profile, so when the laptop
moves to another network the stored endpoint goes stale: Lakekeeper times out
writing table metadata to MinIO (`Unknown S3 error during write … minimum
throughput was specified at 1 B/s, but throughput of 0 B/s was observed`), and
**every workflow execution fails at startup** with
`org.apache.iceberg.exceptions.RESTException: Unable to process:` (empty error
body) thrown from `createTable`. Reads of existing tables keep working (table
metadata is served from Lakekeeper's own Postgres), which makes the failure
look unrelated to networking.
Reproduce: run `bin/local-dev.sh up` on network A, move the machine to
network B, execute any workflow.
### Proposed Solution or Design
On every `up`, compare the host's current IP with the endpoint stored in the
warehouse's storage profile (`GET /management/v1/warehouse/{id}`). When they
differ, refresh it with a single management-API call — `POST
/management/v1/warehouse/{id}/storage`, reusing the existing profile with the
updated endpoint and the MinIO credentials the compose already provisions.
About a dozen lines in `bin/local-dev/main.sh`; the only user-visible change is
a log line. Today the recovery is a manual curl against the management API (or
recreating the warehouse).
### Affected Area
Deployment
--
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]
