# SLZ Job Manager Lambda

## Lambda Environment variables
To execute the Job Manager Lambda the following environment variables must be configured:

| Variable                    | Description                                   |
|-----------------------------|-----------------------------------------------|
| `ENVIRONMENT`               | Environment name (`prod`, `dev`).             |
| `CONFIG_BUCKET`             | Name of S3 bucket with config files.          |
| `DSP_CONFIG_KEY`            | S3 key for DSP config.                        |
| `DSP_COMPLETION_CONFIG_KEY` | s3 key for completion criterias config.       |
| `SLZ_FLOW_CONFIG_KEY`       | s3 key for config with sf arns                |
| `ECS_RUN_CONFIG_KEY`          | s3 key for config with basic payload for slz-downloader|
| `SNS_TOPIC_ARN_REPROCESSING` | topic to publish messages when starting a reprocessing. |
| `RDS_SECRETS_KEY` | Path to secret with DB creds |
| `SENTRY_SECRET_KEY` | Path to secret with sentry urls|

## Lambda Input regular
```json
{
    "time": "2021-08-26T03:05:31Z"
}
```

## Lambda Input reprocessing logic
In order to start lambda in a "reprocessing mode", 
list of UOW ids and priorities (optional) must be specified. Here is the example input data structure:
```json
{
    "time": "2021-08-26T03:05:31Z",
    "reprocessing": [
        {
            "unit_of_work_id": 123,
            "priority": 1
        }, {
            "unit_of_work_id": 345,
            "priority": 5
        },
        ...
        {
            "unit_of_work_id": 667,
            "priority": 9
        }
    ]
}
```
> Note. The default priority (5) will be used if it is not specified.

## Lambda Output
In case of successful lambda execution the following output will be provided:
```json
{
    "meta": {
        "status": "OK"
    }
}
```

If any kind of exception occurred, the response will look like the following:
```json
{
    "meta": {
        "status": "FAILURE",
        "message": <exception message>
    }
}
```
## Creating units explanation.
Units are created based on schedule. Next_run_at = next schedule date based on crontab rule 
1. launch JM with payload `{"time": "2021-08-26T00:05:31Z"}`. Unit has schedule `'*/30 * * * *'`.
Next_run_at will be `"2021-08-26T00:30:31Z"`.
   
2. launch JM with payload `{"time": "2021-08-26T05:07:31Z"}`. Unit has schedule `'*/30 * * * *'`.
Next_run_at will be `"2021-08-26T05:30:31Z"`.
   
3. launch JM with payload `{"time": "2021-08-26T00:07:31Z"}`. Unit has schedule `'*/30 5-23 * * *'`.
Next_run_at will be `"2021-08-26T05:30:31Z"`.
   
## Scheduling units explanation.
Units are schedules based on crontab rule schedule. 
Next_run_at = next schedule date based on crontab rule on the first day of creating, the further in time
unit are processed, the more rarely its scheduled. Skip crontab schedule dates according to the rule:
timedelta_days_since_created * 2

Lets say we launched JM with payload `{"time": "2021-08-26T00:05:31Z"}`. Unit has schedule `'*/30 * * * *'`.
At the first day schedule will be
- `"2021-08-26T00:30:31Z"`.
- `"2021-08-26T01:00:31Z"`.
- `"2021-08-26T01:30:31Z"`.
- `"2021-08-26T02:00:31Z"`.
- `"2021-08-26T02:30:31Z"`.
- ...

on the next day(2021-08-26) schedule will be
- `"2021-08-26T00:30:31Z"`.
- `"2021-08-26T02:00:31Z"`.
- `"2021-08-26T03:30:31Z"`.
- `"2021-08-26T05:00:31Z"`.
- `"2021-08-26T07:30:31Z"`.
- ...

because it's 1 day since created and timedelta_days_since_created(1) * 2 = 2 so
- `"2021-08-26T00:30:31Z"`.
- `"2021-08-26T01:00:31Z"`. - skip
- `"2021-08-26T01:30:31Z"`. - skip
- `"2021-08-26T02:00:31Z"`.
- `"2021-08-26T02:30:31Z"`. - skip
- ...

on the next day(2021-08-27) its 2 days since created date and schedule will be
- `"2021-08-26T00:30:31Z"`.
- `"2021-08-26T03:00:31Z"`.
- `"2021-08-26T05:30:31Z"`.
- `"2021-08-26T08:00:31Z"`.
- ...