Cleanup

Author: erazemk

fern/docs/pages/adaas/loading-phases.mdx

@@ -1,37 +1,44 @@
-For the attachment extraction phase of the import process, the extractor has to upload each attachment to DevRev’s S3
-using the `S3Interact` API.
+For the attachment extraction phase of the import process, the extractor has to upload each
+attachment to DevRev's S3 using the `S3Interact` API.
 
 ## Triggering event
 
-Airdrop initiates the attachment extraction by starting the snap-in with a message with an event of type `EXTRACTION_ATTACHMENTS_START`.
+Airdrop initiates the attachment extraction by starting the snap-in with a message with an event of
+type `EXTRACTION_ATTACHMENTS_START`.
 This is done after the data extraction, transformation and loading into DevRev are completed.
 
 During the attachment extraction phase,
 the snap-in extracts attachments from the external system and uploads them as artifacts to DevRev.
 
-The snap-in must respond to Airdrop with a message with an event of type `EXTRACTION_ATTACHMENTS_PROGRESS` together with an optional progress estimate and relevant artifacts
+The snap-in must respond to Airdrop with a message with an event of type
+`EXTRACTION_ATTACHMENTS_PROGRESS` together with an optional progress estimate and relevant artifacts
 when it extracts some data and the maximum snap-in run time (12 minutes) has been reached.
 
-The snap-in must respond to Airdrop with a message with an event of type `EXTRACTION_ATTACHMENTS_DELAY` and specify a back-off time
-when the extraction has been rate-limited by the external system and back-off is required.
+The snap-in must respond to Airdrop with a message with an event of type `EXTRACTION_ATTACHMENTS_DELAY`
+and specify a back-off time when the extraction has been rate-limited by the external system and
+back-off is required.
 
-In both cases, Airdrop starts the snap-in with a message with an event of type `EXTRACTION_ATTACHMENTS_CONTINUE`.
-The restart is immediate in case of `EXTRACTION_ATTACHMENTS_PROGRESS`, or delayed
-in case of `EXTRACTION_ATTACHMENTS_DELAY`.
+In both cases, Airdrop starts the snap-in with a message with an event of type
+`EXTRACTION_ATTACHMENTS_CONTINUE`.
+The restart is immediate in case of `EXTRACTION_ATTACHMENTS_PROGRESS`, or delayed in case of
+`EXTRACTION_ATTACHMENTS_DELAY`.
 
-Once the attachment extraction phase is done, the snap-in must respond to Airdrop with a message with an event of type `EXTRACTION_ATTACHMENTS_DONE`.
+Once the attachment extraction phase is done, the snap-in must respond to Airdrop with a message
+with an event of type `EXTRACTION_ATTACHMENTS_DONE`.
 
-If attachment extraction fails the snap-in must respond to Airdrop with a message with an event of type `EXTRACTION_ATTACHMENTS_ERROR`.
+If attachment extraction fails the snap-in must respond to Airdrop with a message with an event of
+type `EXTRACTION_ATTACHMENTS_ERROR`.
 
 ## Snap-in response
 
-After uploading an attachment or a batch of attachments, the extractor also has to prepare and upload a file specifying
-the extracted and uploaded attachments.
+After uploading an attachment or a batch of attachments, the extractor also has to prepare and
+upload a file specifying the extracted and uploaded attachments.
 
-It should contain the DevRev IDs of the extracted and uploaded attachments, along with the parent domain object ID
-from the external system and the actor ID from the external system.
+It should contain the DevRev IDs of the extracted and uploaded attachments, along with the parent
+domain object ID from the external system and the actor ID from the external system.
 
-The uploaded artifact is structured like a normal artifact containing extracted data in JSON Lines (JSONL) format and requires specifying `ssor_attachment` as the item type.
+The uploaded artifact is structured like a normal artifact containing extracted data in JSON Lines
+(JSONL) format and requires specifying `ssor_attachment` as the item type.
 
 ## Examples
 

fern/docs/pages/adaas/attachments-extraction.mdx renamed to fern/docs/pages/airdrop/attachments-extraction.mdx

@@ -1,5 +1,6 @@
-During the deletion phases, the snap-in may clean up its state or other side effects in the third party systems.
-In the most common extraction use cases, there is nothing to do and snap-ins may reply with the completion message.
+During the deletion phases, the snap-in may clean up its state or other side effects in the third
+party systems. In the most common extraction use cases, there is nothing to do and snap-ins may reply
+with the completion message.
 
 ## Data deletion
 
@@ -10,19 +11,19 @@ It is started by sending the worker a message with an event of type `EXTRACTION_
 
 ### Snap-in response
 
-The worker must respond to Airdrop with a message with an event of type `EXTRACTION_DATA_DELETE_DONE` when done or
-`EXTRACTION_DATA_DELETE_ERROR` in case of an error.
+The worker must respond to Airdrop with a message with an event of type `EXTRACTION_DATA_DELETE_DONE`
+when done or `EXTRACTION_DATA_DELETE_ERROR` in case of an error.
 
 ## Attachments deletion
 
 
 ### Triggering event
 
-Airdrop initiates the attachments deletion phase when an import is deleted from the DevRev app, after the data deletion has completed.
+Airdrop initiates the attachments deletion phase when an import is deleted from the DevRev app,
+after the data deletion has completed.
 It is started by sending the snap-in a message with an event of type `EXTRACTION_ATTACHMENTS_DELETE`.
 
 ### Snap-in response
 
-The snap-in must respond to Airdrop with a message with an event of type `EXTRACTION_ATTACHMENTS_DELETE_DONE` when done,
-or `EXTRACTION_ATTACHMENTS_DELETE_ERROR` in case of an error.
-
+The snap-in must respond to Airdrop with a message with an event of type`EXTRACTION_ATTACHMENTS_DELETE_DONE`
+when done, or `EXTRACTION_ATTACHMENTS_DELETE_ERROR` in case of an error.

fern/docs/pages/adaas/data-attachments-deletion.mdx renamed to fern/docs/pages/airdrop/data-attachments-deletion.mdx

@@ -1,15 +1,16 @@
 
-In the data extraction phase, the extractor is expected to call the external system’s APIs
+In the data extraction phase, the extractor is expected to call the external system's APIs
 to retrieve all the items that were updated since the start of the last extraction.
-If there was no previous extraction (the current run is an initial import), then all the items should be extracted.
+If there was no previous extraction (the current run is an initial import),
+then all the items should be extracted.
 
 The extractor must store at what time it started each extraction in its state,
 so that it can extract only items created and/or updated since this date in the next sync run.
 
 ## Triggering event
 
-Airdrop initiates data extraction by starting the snap-in with a message with event of type  `EXTRACTION_DATA_START`
-when transitioning to the data extraction phase.
+Airdrop initiates data extraction by starting the snap-in with a message with event of type
+`EXTRACTION_DATA_START` when transitioning to the data extraction phase.
 
 During the data extraction phase, the snap-in extracts data from an external system,
 prepares batches of data and uploads them in the form of artifacts to DevRev.
@@ -18,33 +19,43 @@ The snap-in must respond to Airdrop with a message with event of type `EXTRACTIO
 together with an optional progress estimate and relevant artifacts
 when it extracts some data and the maximum Airdrop snap-in runtime (12 minutes) has been reached.
 
-If the extraction has been rate-limited by the external system and back-off is required, the snap-in must respond to
-Airdrop with a message with event of type `EXTRACTION_DATA_DELAY` and specifying back-off time with `delay` attribute.
+If the extraction has been rate-limited by the external system and back-off is required, the snap-in
+must respond to Airdrop with a message with event of type `EXTRACTION_DATA_DELAY` and specifying
+back-off time with `delay` attribute.
 
 In both cases, Airdrop starts the snap-in with a message with event of type `EXTRACTION_DATA_CONTINUE`.
-The restarting is immediate (in case of `EXTRACTION_DATA_PROGRESS`) or delayed (in case of `EXTRACTION_DATA_DELAY`).
+The restarting is immediate (in case of `EXTRACTION_DATA_PROGRESS`) or delayed
+(in case of `EXTRACTION_DATA_DELAY`).
 
-Once the data extraction is done, the snap-in must respond to Airdrop with a message with event of type  `EXTRACTION_DATA_DONE`.
+Once the data extraction is done, the snap-in must respond to Airdrop with a message with event of
+type  `EXTRACTION_DATA_DONE`.
 
-If data extraction failed in any moment of extraction, the snap-in must respond to Airdrop with a message with event of type  `EXTRACTION_DATA_ERROR`.
+If data extraction failed in any moment of extraction, the snap-in must respond to Airdrop with a
+message with event of type `EXTRACTION_DATA_ERROR`.
 
 ## Snap-in response
 
-During the data extraction phase, the snap-in uploads batches of extracted items (the recommended batch size is 2000 items) formatted in JSONL
-(JSON Lines format), gzipped, and submitted as an artifact to S3Interact (with tooling from `@devrev/adaas-sdk`).
+During the data extraction phase, the snap-in uploads batches of extracted items (the recommended
+batch size is 2000 items) formatted in JSONL (JSON Lines format), gzipped, and submitted as an
+artifact to S3Interact (with tooling from `@devrev/adaas-sdk`).
 
-Each artifact is submitted with an `item_type`, defining a separate domain object from the external system and matching the `record_type` in the provided metadata.
+Each artifact is submitted with an `item_type`, defining a separate domain object from the
+external system and matching the `record_type` in the provided metadata.
 Item types defined when uploading extracted data must validate the declarations in the metadata file.
 
 Extracted data must be normalized.
 
-- Null values: All fields without a value should either be omitted or set to null. For example, if an external system provides values such as "", -1 for missing values, those must be set to null.
-- Timestamps: Full-precision timestamps should be formatted as RFC3999 (`1972-03-29T22:04:47+01:00`), and dates should be just `2020-12-31`.
+- Null values: All fields without a value should either be omitted or set to null.
+For example, if an external system provides values such as "", -1 for missing values,
+those must be set to null.
+- Timestamps: Full-precision timestamps should be formatted as RFC3999 (`1972-03-29T22:04:47+01:00`),
+and dates should be just `2020-12-31`.
 - References: references must be strings, not numbers or objects.
 - Number fields must be valid JSON numbers (not strings)
 - Multiselect fields must be provided as an array (not CSV)
 
-Each line of the file contains an `id` and the optional `created_date` and `modified_date` fields in the beginning of the record.
+Each line of the file contains an `id` and the optional `created_date` and `modified_date` fields
+in the beginning of the record.
 All other fields are contained within the `data` attribute.
 
 ```json
@@ -68,4 +79,4 @@ Extracted artifacts can be validated with the `chef-cli` using the following com
 
 ```bash
 $ chef-cli validate-metadata -m external_domain_metadata.json -r issue < extractor_issues_2.json
-```
+```

fern/docs/pages/adaas/data-extraction.mdx renamed to fern/docs/pages/airdrop/data-extraction.mdx

@@ -1,37 +1,42 @@
-In the external sync unit extraction phase, the extractor is expected to obtain a list of external sync units
-that it can extract with the provided credentials and send it to Airdrop in its response.
+In the external sync unit extraction phase, the extractor is expected to obtain a list of external
+sync units that it can extract with the provided credentials and send it to Airdrop in its response.
 
 An _external sync unit_ refers to a single unit in the external system that we are airdropping to DevRev.
-In some systems, this is a project; in some it is a repository; in support systems it could be called a brand or an organization.
+In some systems, this is a project; in some it is a repository; in support systems it could be
+called a brand or an organization.
 What a unit of data is called and what it represents depends on the external system's domain model.
 It usually combines contacts, users, work-like items, and comments into a unit of domain objects.
 
 Some external systems may offer a single unit in their free plans,
 while their enterprise plans may offer their clients to operate many separate units.
 
-The external sync unit ID is the identifier of the sync unit (project, repository or similar) in the external system.
+The external sync unit ID is the identifier of the sync unit (project, repository or similar)
+in the external system.
 For GitHub, this would be the repository, for example `cli` in `github.com/devrev/cli`.
 
 ## Triggering event
 
 External sync unit extraction is executed only during the initial import.
-It extracts external sync units available in the external system,
-so that the end user can choose which external sync unit should be airdropped during the creation of an **Import** in the DevRev App.
+It extracts external sync units available in the external system, so that the end user can choose
+which external sync unit should be airdropped during the creation of an **Import** in the DevRev App.
 
-Airdrop initiates the external sync unit extraction phase by starting the worker with a message with an event of type
-`EXTRACTION_EXTERNAL_SYNC_UNITS_START`.
+Airdrop initiates the external sync unit extraction phase by starting the worker with a message
+with an event of type `EXTRACTION_EXTERNAL_SYNC_UNITS_START`.
 
-The snap-in must respond to Airdrop with a message with an event of type `EXTRACTION_EXTERNAL_SYNC_UNITS_DONE`, which contains
-a list of external sync units as a payload, or `EXTRACTION_EXTERNAL_SYNC_UNITS_ERROR` in case of an error.
+The snap-in must respond to Airdrop with a message with an event of type
+`EXTRACTION_EXTERNAL_SYNC_UNITS_DONE`, which contains a list of external sync units as a payload,
+or `EXTRACTION_EXTERNAL_SYNC_UNITS_ERROR` in case of an error.
 
 ## Snap-in response
 
-The snap-in provides the list of external sync units in the provided event message `event_data.external_sync_units` containing the following fields:
+The snap-in provides the list of external sync units in the provided event message
+`event_data.external_sync_units` containing the following fields:
 - `id`: The unique identifier in the external system.
 - `name`: The human-readable name in the external system.
 - `description`: The short description if the external system provides it.
 - `item_count`: The number of items (issues, tickets, comments or others) in the external system.
-Item count should be provided if it can be obtained in a very lightweight manner, such as by calling an API endpoint.
+Item count should be provided if it can be obtained in a very lightweight manner,
+such as by calling an API endpoint.
 If there is no such way to get it (for example, if the items would need to be extracted to count them),
 then the item count should be `-1` to avoid blocking the import with long-running queries.
 

fern/docs/pages/adaas/external-sync-units-extraction.mdx renamed to fern/docs/pages/airdrop/external-sync-units-extraction.mdx

@@ -1,11 +1,11 @@
-# Extraction
+Airdrop extractions are done in _sync runs_.
+A sync run is one execution of an import or sync.
+If you do an initial import from the external system to DevRev, that import will be one sync run.
+If you then decide to do a reverse sync from DevRev to the external system, that would be another
+sync run.
 
-Airdrop extractions are done in _sync runs_. A sync run is one execution of an import or sync. If you do an initial import from
-the external system to DevRev, that import will be one sync run. If you then decide to do a reverse sync from DevRev to
-the external system, that would be another sync run.
-
-Each sync run is comprised out of phases. Phases follow sequentially, and each can consist of one or more invocations
-of the snap-in.
+Each sync run is comprised out of phases.
+Phases follow sequentially, and each can consist of one or more invocations of the snap-in.
 
 ```mermaid
 sequenceDiagram
@@ -84,12 +84,13 @@ An _initial import_ consists of the following phases:
 ### 1-way sync
 
 A _1-way sync_ refers to any extraction after the initial import has been successfully completed.
-An extractor extracts data that was created and/or updated in the external system
-after the start of the latest successful forward sync, including any changes that occurred during the
-forward sync, but were not picked up by it.
+An extractor extracts data that was created and/or updated in the external system after the start
+of the latest successful forward sync, including any changes that occurred during the forward sync,
+but were not picked up by it.
 
-A snap-in must consult its state to get information on when the last successful forward sync started. Airdrop snap-ins
-must maintain their own states that persists between phases in a sync run, as well as between sync runs.
+A snap-in must consult its state to get information on when the last successful forward sync started.
+Airdrop snap-ins must maintain their own states that persists between phases in a sync run,
+as well as between sync runs.
 
 A 1-way sync consists of the following phases:
 1. Metadata extraction
@@ -104,4 +105,3 @@ A 1-way sync extracts only the domain objects updated or created since the previ
 A _deletion_ consists of the following phases:
 1. Data deletion
 2. Attachments deletion
-

fern/docs/pages/adaas/extraction-phases.mdx renamed to fern/docs/pages/airdrop/extraction-phases.mdx

@@ -1,7 +1,8 @@
 ## Before you begin
 
 - If you have not created a development organization on DevRev before, create a dedicated
-  [DevRev organization for development purposes](https://app.devrev.ai/) where you will be publishing your Airdrop snap-in.
+[DevRev organization for development purposes](https://app.devrev.ai/) where you will be
+publishing your Airdrop snap-in.
 - Install required tools and packages:
   - [devrev-cli](https://developer.devrev.ai/snapin-development/references/cli-install) (version 4.7 or higher)
   - [jq](https://stedolan.github.io/jq)
@@ -10,8 +11,8 @@
 
 ## Setting up the snap-in
 
-1. Create a new repo from the [Airdrop template repo](https://github.com/devrev/adaas-template). Select _Use this template_ and
-   then _Create a new repository_.
+1. Create a new repo from the [Airdrop template repo](https://github.com/devrev/adaas-template).
+Select _Use this template_ and then _Create a new repository_.
 1. Copy `.env.example` to `.env` and fill in the required variables.
 1. Configure a keyring for the external system in the `manifest.yaml`.
    Refer to [Keyrings](/snapin-development/references/manifest#developer-keyrings) for instructions.

fern/docs/pages/adaas/faq.mdx renamed to fern/docs/pages/airdrop/faq.mdx

@@ -0,0 +1,3 @@
+# Loading
+
+To be added.