Airbyte is an open-source data integration engine that helps you consolidate your data in your data warehouses, lakes and databases.

Airbyte

*1st question*
```[1:10 AM] job_info: {
  attempts: [...]
  job: {
    id: 126, 
    configType: "check_connection_source", 
    createdAt: 1608847715,
    id: 126,
    status: "succeeded",
    updatedAt: 1608847719
  },
  message: "(401, 'The access token is invalid or has expired')",
  status: "failed",
}```
for `v1/scheduler/sources/check_connection` and `v1/scheduler/destination/check_connection`
I receive  `status: "failed"` . But in `job_info.job` we have `status: "succeeded"`

there are 2 separate concepts here. the job and the outcome of the check connection.

there are 3 possible outcomes for a check connection run:
• job failed, check connection:failed
• job succeeded, check connection: failed
• job succeeded, check connection: succeeded

if the job fails we assume that check connection failed.

that is if the job trying to run the check connection fails, we assume that we not able to make a connection. (the api always set the check connection status to false in this case).

if the job succeeds, it's still possible that we were unable to connect, it just means that we were able to catch the exception (and usually provide a better error messagE).

i think from the UI point of view when showing the connection status the ui always should use the connection status (not the job status).

when showing the job logs, however, it can keep the same logic that is use for showing job logs / attempts every where else (in other words it is just looking at the job.status.

Ok. I think I understand now. Thank you a lot. 