Summary:
feat(bootstrap): automatically init submodule if able
fix(bootstrap): symlink arc instead of copy
Test Plan: test
Reviewers: juan
Differential Revision: https://phab.nylas.com/D3494
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).
