Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate POST "failed" bsos #418

Open
pjenvey opened this issue Jan 23, 2020 · 1 comment
Open

Deprecate POST "failed" bsos #418

pjenvey opened this issue Jan 23, 2020 · 1 comment
Labels
3 Estimate - m - This is a small change, but there's some uncertainty. enhancement New feature or request

Comments

@pjenvey
Copy link
Member

pjenvey commented Jan 23, 2020

@mhammond outlines this here: #376 (comment)

Individual bsos can fail during a multi-write (regular POST or a batch) when others succeed. This poses complications for Sync clients: they would prefer multi-writes either completely succeeded or completely failed.

In Python syncstorage and our Spanner backend the only bsos added to failed are those that failed validation. Our mysql backend also adds bsos that failed to write due to DbErrors (along with a TODO to remove this).

To deprecate this, we could stop adding bsos to the failed collection entirely and let validation (40x) or db errors (50x) encountered fail and rollback the entire operation.

@pjenvey pjenvey added enhancement New feature or request 3 Estimate - m - This is a small change, but there's some uncertainty. labels Jan 23, 2020
@pjenvey pjenvey added this to Backlog: Misc in Services Engineering via automation Jan 23, 2020
@tublitzed tublitzed moved this from Backlog: Misc to Backlog: Sync in Services Engineering Feb 3, 2020
@pjenvey pjenvey moved this from Backlog: Sync to Prioritized in Services Engineering Apr 10, 2020
@pjenvey
Copy link
Member Author

pjenvey commented Apr 10, 2020

Upping the priority of this. The forms bug #480 made it evident how bad this "failed" feature is. Ops pointed out that clients may been uploading batches of forms with all of them failing due to the bug and the client would have ignored them w/ the batch still succeeding.

We'll likely recover from this bug without further intervention (see https://bugzilla.mozilla.org/show_bug.cgi?id=1627410) but we might not be so lucky in the future.

Per: https://bugzilla.mozilla.org/show_bug.cgi?id=1627410#c16 -- the client does in fact retry uploading failed records.

@pjenvey pjenvey moved this from Prioritized to Scheduled in Services Engineering Oct 3, 2020
@pjenvey pjenvey moved this from Scheduled to Prioritized in Services Engineering Oct 12, 2020
jrconlin added a commit that referenced this issue Oct 12, 2020
* chore: update to protobuf 2.18.0

Closes #852
Issue #418
@pjenvey pjenvey moved this from Prioritized to Backlog: Sync in Services Engineering Dec 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3 Estimate - m - This is a small change, but there's some uncertainty. enhancement New feature or request
Projects
Services Engineering
  
Backlog: Sync
Development

No branches or pull requests

2 participants