linliu-code opened a new issue, #20128: URL: https://github.com/apache/hudi/issues/20128
StorageBasedLockProvider releases a lock by writing an expired marker to the lock file. When that expire write fails with an indeterminate storage error (for example an S3 SdkClientException "Unable to execute HTTP request: Remote end is closed" from a stale pooled connection), the storage client returns UNKNOWN_ERROR, the provider maps it to a terminal FAILED, and unlock() throws FAILED_TO_RELEASE after a single attempt. The lock file then stays un-expired until its lease elapses (5 minutes by default), every writer on the table is blocked for that time, and the next acquirer reports a dangling lock. The storage clients are built with SDK retries disabled, and the release retry loop in unlock() only covers THROTTLED (and, with #20028, 5xx). So a single transient connection-level failure on the release write always strands the lock. Retrying is safe: the expire write is conditional on the lock file version we hold, so a retry cannot overwrite another writer, and a retry that fails its precondition because the first attempt actually landed can be reconciled by reading the lock file back. Related: #20027 (the same failure for HTTP 5xx, fixed by #20028). -- 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]
