Aedrian E.

Hey Greg O., to answer your questions:

If R2 rejects DeleteObject because of a bucket-lock rule, does ducklake_cleanup_old_files leave the file scheduled and safely retryable without removing its metadata record?

When a file cannot be cleaned up due to a bucket-lock rule, you'll get an IO error, and you can retry ducklake_cleanup_old_files again because the files_scheduled_for_deletion record is unchanged Hope this helps!

Hey Greg O., one option you could do is to reset your duckling (Settings > Ducklings > Reset Duckling). This will stop all running queries though, not just the one you want to cancel. Could you also try cancelling the query with MD_INTERRUPT_SERVER_CONNECTION? You can get the client connection id from md_active_server_connections()

SELECT md_interrupt_server_connection(<client_connection_id>);

Hey Prudvi, thanks for reaching out! Just to confirm, were you following this guide? motherduck.com/docs/integrations/bi-tools/looker Did you run into any errors? If so, could you share what you got?

ducklake_cleanup_old_files does physically the delete Parquet files on your bucket. However, the failsafe only allows you to recover the metadata catalog for up to 7 days, but it won't cover the objects in R2. Hope this helps!

Hey Greg O., we're looking into this!

Our team has identified the root cause of the elevated error rates and has released a fix. We are observing reduced error rates, and our systems are steadily returning to normal operation. We are monitoring the situation closely. Apologies for the impact this has caused! If you are still experiencing any errors or issues, please don't hesitate to reach out!

We've identified the root cause and are working on a fix. We'll provide more updates shortly!

We are investigating this issue with high priority and will provide updates via our status page at https://status.motherduck.com and here. Apologies for the inconvenience!

You're welcome! I agree, errors arising out of network instability can be misleading. We have this as part of our roadmap. For the OOM being able to print the actual statement executed, yes, it is more of a duckdb solution. I've also submitted a feature request internally to consider having a "real" TRUNCATE, one that does not just do a DELETE FROM under the hood and does not require a lot of memory to execute.

Hey Nick C., I wanted to give you an update on Issue #2. In duckdb, TRUNCATE is an alias to DELETE FROM , therefore it is possible to run into an OOM when there is not enough memory allocated to the duckling. Given that, the workaround that you have (DROP + CREATE) is our alternative at the moment