Closed Bug 1253112 Opened 5 years ago Closed 4 years ago

[iOS] Upload bookmark records atomically

Categories

(Firefox for iOS :: Sync, defect, P1)

All
Android
defect

Tracking

()

RESOLVED FIXED
Iteration:
1.3
Tracking Status
fxios-v6.0 --- fixed

People

(Reporter: rnewman, Assigned: sleroux, Mentored)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [sync-atomic][MobileAS])

Attachments

(1 file)

This is the iOS equivalent of Bug 1253051. See that bug for details.
Blocks: 1252469
Blocks: 1196238
See Also: → 1261186
See Also: → 1263339
Priority: -- → P1
Whiteboard: [data-integrity]
I can take a stab at this. Putting :rnewman as a mentor :)
Assignee: nobody → sleroux
Mentor: rnewman
Attachment #8773442 - Flags: feedback?(rnewman) → feedback+
I don't understand swift, but one thing that stands out: The way the spec is written, we can't know the batch semantics of the server until we make the first post (and thus have already enqueued a number of records). It's not clear this is handled here - or maybe the intent was to deduce the server semantics from the result of the info/configuration endpoint and fail if we thought the server was going to give us a batch but didn't? Best I can tell this patch doesn't hit info/configuration at all, nor use the batch limits it returns, so maybe that will become clearer in later versions of the patch?
Summary: Upload bookmark records atomically → [iOS] Upload bookmark records atomically
On iOS we don't support custom servers, so we don't have to worry too much about non-supported batch operations; see Bug 1254402 for using i/conf.
Whiteboard: [data-integrity] → [data-integrity][MobileAS s1.1]
(In reply to Richard Newman [:rnewman] from comment #5)
> On iOS we don't support custom servers, so we don't have to worry too much
> about non-supported batch operations; see Bug 1254402 for using i/conf.

FWIW, I believe the plan for rolling out the server side of this is "slowly" :) It's tricky to fully simulate a production load, so I believe ops will enable this per-node and disable it if any problems are found (then presumably tweak, rinse and repeat). In practice, this means a patch that assumes batch semantics can only land once the config is enabled for all nodes and ops are confident they will never need to turn it off.

(Richard says something similar in bug 1254402 comment 2, but I thought it worth explicitly calling out here)
Whiteboard: [data-integrity][MobileAS s1.1] → [sync-atomic][MobileAS s1.1]
Whiteboard: [sync-atomic][MobileAS s1.1] → [sync-atomic][MobileAS s1.2]
Status: NEW → ASSIGNED
Whiteboard: [sync-atomic][MobileAS s1.2] → [sync-atomic][MobileAS s1.3]
Priority: P1 → P2
Whiteboard: [sync-atomic][MobileAS s1.3] → [sync-atomic][MobileAS]
Priority: P2 → P1
Depends on: 1297561
master https://github.com/mozilla/firefox-ios/commit/d3cfc32d80df8d8ecd1c86ad251def2071c1a0f5
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Iteration: --- → 1.3
You need to log in before you can comment on or make changes to this bug.