What I missed on my earlier reading of the object server code is that when there is no X-Delete-At-Partition, an async update is still written for the expiring objects account...so these warnings are not completely insignificant because they indicate those async updates will written [1] be using a delete_at_container calculated using the object server's expiring_objects_container_divisor value which is precisely what the original bug fix [2] was trying to avoid.
So a better solution might be to ensure all backend object requests actually have the x-container-delete-at-* headers, which will result in some duplicated updates, but that duplication is already happening async, and some duplication is necessary to avoid a bug similar to [3][4].
What I missed on my earlier reading of the object server code is that when there is no X-Delete- At-Partition, an async update is still written for the expiring objects account...so these warnings are not completely insignificant because they indicate those async updates will written [1] be using a delete_at_container calculated using the object server's expiring_ objects_ container_ divisor value which is precisely what the original bug fix [2] was trying to avoid.
So a better solution might be to ensure all backend object requests actually have the x-container- delete- at-* headers, which will result in some duplicated updates, but that duplication is already happening async, and some duplication is necessary to avoid a bug similar to [3][4].
[1] https:/ /gist.github. com/alistairnco les/19cab149565 4c9c0e02f7222c5 d1ce3e /review. openstack. org/#/c/ 31584/ /bugs.launchpad .net/swift/ +bug/1460920 /github. com/openstack/ swift/commit/ 3f943cfcf2de26e 51f1ace96f2c28a 36ab105887
[2] https:/
[3] https:/
[4] https:/