feat: Enhance the output while writer close with error

[carlsverre]

Describe the bug

I see the following error on Tigris and Minio when using WriteOption::if_not_exists:

060.244s DEBUG Action::run{action=RemoteCommit { vid: 3nXPhhLYtD7ZN }}:put_commit{log=74ggeHXDbm-2tZGLRnRwZAeQ lsn=8}: opendal::services: service=s3 name=graft-primary path=logs/74ggeHXDbm-2tZGLRnRwZAeQ/commits/fffffffffffffff7: write started
060.245s DEBUG Action::run{action=RemoteCommit { vid: 3nXPhhLYtD7ZN }}:put_commit{log=74ggeHXDbm-2tZGLRnRwZAeQ lsn=8}: opendal::services: service=s3 name=graft-primary path=logs/74ggeHXDbm-2tZGLRnRwZAeQ/commits/fffffffffffffff7: write created writer
060.334s  WARN Action::run{action=RemoteCommit { vid: 3nXPhhLYtD7ZN }}:put_commit{log=74ggeHXDbm-2tZGLRnRwZAeQ lsn=8}: opendal::services: service=s3 name=graft-primary path=logs/74ggeHXDbm-2tZGLRnRwZAeQ/commits/fffffffffffffff7 written=105: write close failed ConditionNotMatch (persistent) at write, context: { uri: https://t3.storage.dev/graft-primary/logs/74ggeHXDbm-2tZGLRnRwZAeQ/commits/fffffffffffffff7, response: Parts { status: 412, version: HTTP/1.1, headers: {"access-control-allow-headers": "*", "access-control-allow-methods": "*", "access-control-allow-origin": "*", "access-control-expose-headers": "*", "content-length": "400", "content-type": "application/xml", "server": "Tigris OS", "server-timing": "total;dur=50", "strict-transport-security": "max-age=63072000; includeSubDomains; preload", "x-amz-request-id": "1765944010531049946", "date": "Wed, 17 Dec 2025 04:00:10 GMT"} }, service: s3, path: logs/74ggeHXDbm-2tZGLRnRwZAeQ/commits/fffffffffffffff7, written: 105 } => S3Error { code: "PreconditionFailed", message: "At least one of the pre-conditions you specified did not hold", resource: "/graft-primary/logs/74ggeHXDbm-2tZGLRnRwZAeQ/commits/fffffffffffffff7", request_id: "1765944010531049946" }
060.334s DEBUG Action::run{action=RemoteCommit { vid: 3nXPhhLYtD7ZN }}:put_commit{log=74ggeHXDbm-2tZGLRnRwZAeQ lsn=8}: opendal::services: service=s3 name=graft-primary path=logs/74ggeHXDbm-2tZGLRnRwZAeQ/commits/fffffffffffffff7 written=105: write close failed
060.334s  WARN Action::run{action=RemoteCommit { vid: 3nXPhhLYtD7ZN }}:put_commit{log=74ggeHXDbm-2tZGLRnRwZAeQ lsn=8}: opendal_core::layers::complete: writer has not been closed or aborted, must be a bug

Steps to Reproduce

Write to Tigris or Minio (and possibly other object_stores) using this request:

        self.store
            .write_options(
                &path,
                commit.encode_to_bytes(),
                WriteOptions {
                    // Perform an atomic write operation, returning
                    // a precondition error if the commit already exists
                    if_not_exists: true,
                    concurrent: REMOTE_CONCURRENCY,
                    ..WriteOptions::default()
                },
            )
            .await?;

Expected Behavior

The writer is properly closed, or the CompletionLayer treats this as an expected case.

Additional Context

No response

Are you willing to submit a PR to fix this bug?

• Yes, I would like to submit a PR.

[dosubot]

Hi @carlsverre! I'm Dosu and I’m helping the opendal team.

This is a known and recurring bug in OpenDAL, especially with S3-compatible backends like Tigris and Minio, when using atomic write options such as if_not_exists. The warning from CompletionLayer ("writer has not been closed or aborted, must be a bug") is triggered when a write operation fails due to a precondition error (like HTTP 412 PreconditionFailed), and the writer is not properly closed or aborted. This issue has been reported in several contexts, including precondition failures, AlreadyExists, NotFound, and network/backend errors, and is linked to improper writer lifecycle management during error handling—often with concurrency or retries involved [5101, 4780, 4012].

The maintainers recognize this as a bug and are actively investigating and working on fixes. As a workaround, some have suggested explicitly aborting the writer on error or checking file existence after a failed close, but the underlying issue is that writers should always be finalized (closed or aborted) in all error cases [5101].

If you need to mitigate the warning in the meantime, you could try catching the error from writer.close() and explicitly aborting the writer, or verifying file existence after a precondition failure. For a long-term solution, the relevant code paths in CompletionLayer and writer error handling will need to be updated to ensure proper cleanup in all scenarios.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[Xuanwo]

The writer is properly closed, or the CompletionLayer treats this as an expected case.

Yes, I think we shouldn't print this message while writers already hit an error. This error is designed to catch misuse like creating a writer but never close or abort it.

[Xuanwo]

Hi, @carlsverre Do you have any interest in helping to fix this? I think we could add a flag in CompleteLayer to indicate whether the writer has been properly closed.

[carlsverre]

Seems like a simple fix if it's just a flag. I wasn't sure if that would be correct as I'm pretty new to the codebase. I'll send a PR with what I think would do it, and you can tell me where I'm wrong :)