Fix incorrect collection delete behaviour

[mostlygeek]

When deleting a collection the behaviour should be:

• the collection's last-modified timestamp should be reset to 0
• the collection no longer shows up in /info/collections
• last modified timestamp of the entire store should be set to current

[rfk]

👍 let's also ensure that the functional tests accurately exercise this

[mhammond]

Further, I believe that desktop will make its next POST with x-if-unmodified-since being set to the previous value of the collection's last-modified timestamp - so it is probably also necessary to ensure that a POST to an empty collection allows a non-zero x-i-u-s header.

[mhammond]

so it is probably also necessary to ensure that a POST to an empty collection allows a non-zero x-i-u-s header.

My brain was back-to-front - we should get that "for free" - a non existing collection isn't modified after any date you specify (ie, assuming last-modified really is zero, that's not a special case)

But I came here to say that the python server will 404 on a GET for a non-existing collection. Nothing (probably) breaks if it returned 200 with an empty result set, but we might as well have the 2 impls be consistent.

[mostlygeek]

But I came here to say that the python server will 404 on a GET for a non-existing collection. Nothing (probably) breaks if it returned 200 with an empty result set, but we might as well have the 2 impls be consistent.

The python functional tests expect a 200 and [] for the body for non existent collections. See test_get_collection.

[mhammond]

According to https://bugzilla.mozilla.org/show_bug.cgi?id=687299, that was changed 5 years ago. This is coming up because https://bugzilla.mozilla.org/show_bug.cgi?id=1347807 is to change our local test server to match this. 😕

[rfk]

Hrm, that's surprising to me, but can't argue with the tests....I'll have to dig into the details here more tomorrow :-(

[mostlygeek]

Should land #170 and mozilla-services/server-syncstorage#62 before landing #171. That way #171 will pass the latest sync functional tests.

[rfk]

According to https://bugzilla.mozilla.org/show_bug.cgi?id=687299, that was changed 5 years ago.

My archeological expedition reveals that this change was reverted in [1], because we are forever doomed to wander the forsaken wastes, haunted by spectral shadows raised from the ancient tomes, from lore that we ourselves laid down in what was a more innocent time.

Which is to say, for backwards-compatibility with sync1.1 client behaviour.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=963332