**Apache Airflow version**: 2.0.0


**Kubernetes version (if you are using kubernetes)** (use `kubectl version`):

**Environment**:

- **Cloud provider or hardware configuration**:
- **OS** (e.g. from /etc/os-release):
- **Kernel** (e.g. `uname -a`):
- **Install tools**:
- **Others**:

**What happened**:

I have the following DAG:

```py
from datetime import datetime, timedelta

from airflow import DAG
from airflow.operators.bash_operator import BashOperator

with DAG(
    dag_id="sla_trigger",
    schedule_interval="* * * * *",
    start_date=datetime(2020, 2, 3),
) as dag:
    BashOperator(
        task_id="bash_task",
        bash_command="sleep 30",
        sla=timedelta(seconds=2),
    )

```

And in my understanding this dag should result in SLA miss every time it is triggered (every minute). However, after few minutes of running I don't see any SLA misses...

**What you expected to happen**:

I expect to see SLA if task takes longer than expected.

**How to reproduce it**:

Use the dag from above.

**Anything else we need to know**:

N/A

airflow/jobs/scheduler_job.py
command,
                priority=priority,
                queue=queue,
            )
    def _critical_section_execute_task_instances(self, session: Session) -> int:
        """
        Attempts to execute TaskInstances that should be executed by the scheduler.
        There are three steps:
        1. Pick TIs by priority with the constraint that they are in the expected states
        and that we do exceed max_active_runs or pool limits.
        2. Change the state for the TIs above atomically.
        3. Enqueue the TIs in the executor.
        HA note: This function is a "critical section" meaning that only a single executor process can execute
        this function at the same time. This is achieved by doing ``SELECT ... from pool FOR UPDATE``. For DBs
        that support NOWAIT, a "blocked" scheduler will skip this and continue on with other tasks (creating
        new DAG runs, progressing TIs from None to SCHEDULED etc.); DBs that don't support this (such as
        MariaDB or MySQL 5.x) the other schedulers will wait for the lock before continuing.
        :param session:
        :type session: sqlalchemy.orm.Session
        :return: Number of task instance with state changed.
        """
        if self.max_tis_per_query == 0:
            max_tis = self.executor.slots_available
        else:
            max_tis = min(self.max_tis_per_query, self.executor.slots_available)
        queued_tis = self._executable_task_instances_to_queued(max_tis, session=session)
        self._enqueue_task_instances_with_queued_state(queued_tis)
        return len(queued_tis)
    @provide_session
    def _change_state_for_tasks_failed_to_execute(self, session: Session = None):