Sorry for the delayed response; for some reason, this email ended up
in my spam folder.

I have opened a bug report on Launchpad (https://bugs.launchpad.net/swift/+bug/2070397).
Regarding the handling that the dark_data watcher performs for shards
in direct_get_container, this approach is almost identical to the workaround
I implemented to ensure the account-reaper functions as expected.
I have attached the patch file to the bug report. Some variable names
might be confusing at this point, but they can be adjusted as needed.

> This may require some non-trivial work.

Do you have any concerns about this approach?
I'm trying to think about potential scenarios.

Em qui., 20 de jun. de 2024 às 01:48, Pete Zaitcev <zaitcev@redhat.com> escreveu:

On Tue, 4 Jun 2024 14:29:23 -0300
Thiago De Moraes Teixeira <teixeira.thiago@luizalabs.com> wrote:

> First, when deleting the account, account-reaper lists objects from the
> sharded bucket, an empty list is returned from *direct_get_container*
> function,
> so the reaper interprets it as an empty bucket, and the delete fails
> with a 409 Conflict because objects exist inside the bucket.

That looks like a bug. I'm astonished that nobody has encountered
it yet, but users of direct_get_container must check for retuned shards.
There's some sample code in the object watcher,
https://opendev.org/openstack/swift/src/branch/master/swift/obj/watchers/dark_data.py

> ... But in this case, when the reaper tries to
> delete objects inside this account, all objects are not found because
> the object path used is "/.shards_AUTH_<project_id>/<bucket>-<hash>-
> <timestamp>-<shard_index>/<key>" instead of "/AUTH_<project_id>/
> <bucket>/<key>".

Not sure what to say about that.

Either way, I think the best course of action is to file a bug
in Launchpad. This may need some not entirely trivial work.

-- Pete

‘Esta mensagem é direcionada apenas para os endereços constantes no cabeçalho inicial. Se você não está listado nos endereços constantes no cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão imediatamente anuladas e proibidas’.

‘Apesar do Magazine Luiza tomar todas as precauções razoáveis para assegurar que nenhum vírus esteja presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.