Stale container PUT overwrites object count

[David Wagner]

Swift 1.13.0:
AccountBroker.merge_items() compares request-supplied timestamps with existing container timestamps and chooses the newer ones; it then compares the newest put-timestamp with the newest delete-timestamp to decide if the container should be marked deleted or not. This is obviously to prevent a stale delete request from wiping out a live container, or to prevent a stale put request from resurrecting a deleted container. However, the method unconditionally saves the request-supplied object count and bytes used fields into the container record. If the request is stale, this will corrupt these two fields.

[clayg (clay-gerrard)]

I don't think that's there to "prevent a stale delete" - think it's just trying to keep the log up to date - most recent put, most recent delete. Generally speaking I think the account is willing to say the container's updates are authoritative for their bytes used and object counts.

I guess you could *try* to throw out container updates from stale containers...

    if (record[put] < row[put] and record[delete] < row[delete]):
        continue # nothing new to see here.

But think the current code is banking on the container databases eventually sorting themselves out, any container replication event that changes a container's bytes or object count is going to trigger the container updater to resend it's stats to the account...