Describe the bug
Delete request matching in the boltdb implementation uses prefix search (

) to find delete requests corresponding to a particular tenant. As a result, a delete request for tenant tenant-123 is also returned for tenants tenant-12 and tenant-1 and t, etc.

To Reproduce
Steps to reproduce the behavior:

1. Started Loki (v3.5.3) backed by S3 storage with retention enabled.
2. Send a delete request with X-OrgID: tenant-123 via POST at loki/api/v1/delete
3. List delete requests wit X-OrgID: tenant-12 via GET at loki/api/v1/delete
4. See the previously added delete request for tenant-123 there under tenant-12

Expected behavior
Expect to see no delete requests under tenant-12.

Environment:

• Infrastructure: Kubernetes, microservice deployment mode.
• Deployment tool: helm

Impact
Although, the data for the wrong user/tenant tenant-12 is not deleted in S3. Any query for it will filter it out due to the delete request being present. It seems that the querier uses the same compactor endpoint (GET at loki/api/v1/delete) to get the existing delete requests for the tenant and thus it is filtering the result data also for the wrong tenant.