This commit adds a new request type: SyncbackTaskAPIRequest.
This API request is meant to be used for requests that create a
SyncbackRequest inside K2.
When the initial http request succeeds, this means that the task was created,
but we cant tell if the task actually succeeded or failed until some time in
the future when its processed inside K2's sync loop.
A SyncbackTaskAPIRequest will only resolve until the underlying K2 syncback
request has actually succeeded, or reject when it fails, by listening to
deltas for ProviderSyncbackRequests
THis commit also updates N1's tasks that create syncback requests to use
this new type of request
Since local-sync can access the same targetPaths as N1, there's
no need to create actual File instances anymore. Pass just the
upload data in the API request, and remove SyncbackDraftFilesTask
since it is no longer necessary.
Summary:
We now use <pre> tags to preserve whitespace in plaintext emails,
but it's annoying when there are long lines that force a scroll
bar. Wrap them instead.
Test Plan:
looked at some emails. Not sure this isn't going to break something
weird---is <pre> used in anything else?
Reviewers: bengotow
Differential Revision: https://phab.nylas.com/D3484
When running syncback requests, if a task is meant to change the UID of
a message (e.g. move it to a new folder), that task should be run after
other tasks that don't affect the UID. Otherwise, when trying to run the
other tasks, they would reference a UID that is no longer valid.
This commit will make sure that we run any tasks that will change message uids last,
/and/ make sure that we don't run more than 1 task that will affect the uids of
the same messages in a row (i.e. without running a sync loop in between)
This commit will correctly keep track of folder and label ids when
creating them from N1.
Previously, when we sent the request to create a folder or label to our api,
we would immediately get back a serverId because it was created optimistically
in the back end— given that K2 is strictly non-optimistic, we won’t have a serverId
until some undetermined time in the future, and we need to somehow reference
the object that /was/ optimistically created in N1 to update the ui when
we do get the server id.
Since we can deterministically generate ids for folders and labels,
we "guess" what its going to be, and include it in the props of the syncback request
returned to N1. This is the simplest solution to get thing working
correctly right now, but we’ll need to revisit this in the future for
other types of objects (drafts, contacts, events), and revisit how we
will manage optimistic updates in N1 when we merge the 2 codebases
with K2 (given that K2 was designed to be non-optimisitc).
Since message IDs are now static but there's no good way to generate
static thread IDs while syncing an account from newest message first,
we give threads the ID of any message on that thread and, when setting
metadata, look up the local thread ID by first going through the
message table.
Also changed the DeltaProcessor so it doesn’t query for models before sending out `Actions.didPassivelyReceiveCreateDeltas`, and renames it to be more clear it’s about deltas.
Moving to between gmail folders (all, spam, trash) or moving to inbox,
involves changing labels /and/ folders, simultaneously. For this I added
a task to perform both operations, and apply labels first before
attempting to move the folder
Revert "fix(categories): Fix tasks for moving threads in Gmail"
This reverts commit 527de80ad2.
