Store the fact a record is a tombstone in the plaintext part of the payload
Categories
(Firefox :: Sync, enhancement)
Tracking
()
People
(Reporter: markh, Assigned: markh)
Details
Attachments
(1 file)
We can already deduce it with a high degree of reliability simply by looking at the size of the record, so to help the server team avoid deducing, let's just have the deleted
flag in the plain-text. We can also keep it in the encrypted payload, at least for the next few years.
Assignee | ||
Comment 1•4 years ago
|
||
Updated•4 years ago
|
Comment 2•4 years ago
|
||
We'll need to confirm that both Python and Rust sync servers gracefully handle this value before landing this (their might "gracefully handle" it by ignoring it, which is find...but we don't want to them to e.g. return a "400 Bad Request" because of the unexpected plaintext field)
Assignee | ||
Comment 3•4 years ago
|
||
A quick manual test shows it works with sync-1-us-west1-g (which is spanner, right?) and with sync-719-us-west-2
Comment 4•4 years ago
|
||
There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:markh, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 5•4 years ago
|
||
Did we decide that we don't really need this after all?
Assignee | ||
Comment 6•4 years ago
|
||
(In reply to Ryan Kelly [:rfkelly] from comment #5)
Did we decide that we don't really need this after all?
Doing this in app-services in a non-hacky way is tricker than I expected, so we agreed to deprioritize that - and I don't think it's worth landing this until we are ready to land it there.
Comment 7•4 years ago
|
||
Echo-ing what Mark said; it's something that be nice to have on the sync storage side, but re:priority if it's non trivial work on the client side, we're good to de-prioritize for now.
Description
•