Introduce task_attempts

[kirillsalykin]

For a history/debug purpose I think it makes sense to track task attempts in a separate table.

So, next to this:

create table underway.task (
    id                  uuid not null,
    task_queue_name     text not null,
    input               jsonb not null,
    state               underway.task_state not null default 'pending',
    retry_count         integer not null default 0,
    max_attempts        integer not null default 5,
    initial_interval_ms integer not null default 1000,
    max_interval_ms     integer not null default 60000,
    backoff_coefficient real not null default 2.0,
    error_message       text,
    timeout             interval not null default interval '15 minutes',
    ttl                 interval not null default interval '14 days',
    delay               interval not null default interval '0',
    concurrency_key     text,
    priority            integer not null default 0,
    created_at          timestamp with time zone not null default now(),
    updated_at          timestamp with time zone not null default now(),
    started_at          timestamp with time zone,
    succeeded_at        timestamp with time zone,
    last_failed_at      timestamp with time zone,
    primary key (id, task_queue_name),
    foreign key (task_queue_name) references underway.task_queue(name)
);

what do you think about having this:

create table underway.task_attempt (
    id                  uuid not null,
    task_id     uuid not null,
    state               underway.task_state not null default 'pending',
    error_message       text,
    created_at          timestamp with time zone not null default now(),
    updated_at          timestamp with time zone not null default now(),
    started_at          timestamp with time zone,
    finished_at        timestamp with time zone
);

This nicely captures all history of attempts and error_message is not overriden everytime.
(Maybe also make error a jsonb so a little more info can be put there).

(Maybe) Fields started_at, succeeded_at and last_failed_at can be selected from the attempts table, so you dont need to keep the state up to date and keep the task table cleaner.

WDYT?

[maxcountryman]

I'm generally in favor of more observability and think this sounds like a good direction.

One thing to bear in mind here is if this will introduce a join (for example, it would if state is moved to this table).

[kirillsalykin]

Particularly for the state field, I think it should be in both task and task_attempt. For instance, after 2 retries, the task is successfully completed, so the task/state will be succeeded, and the task_attempt/state will be failed, failed, succeeded.

As for the other fields, I'm not entirely sure if normalization (deduplication) is worth it.

[maxcountryman]

I'm intending to look at incorporating this before cutting the 0.1.0 release.