code: protected void verifyStatusTransitionIsValid(JobExecutionEntity exec, BatchStatus toStatus) throws BatchIllegalJobStatusTransitionException {
  
          switch (exec.getBatchStatus()) {
              case COMPLETED:
                  //COMPLETED to ABANDONED is allowed since it's already allowed in released TCK tests.
                  if (toStatus == BatchStatus.ABANDONED) {
                      break;
                  }
              case ABANDONED:
                  throw new BatchIllegalJobStatusTransitionException("Job execution: " + exec.getExecutionId()
                                                                     + " cannot be transitioned from Batch Status: " + exec.getBatchStatus().name()
                                                                     + " to " + toStatus.name());
              case STARTING:
              case STARTED:
              case STOPPING:
              case FAILED:
  
              default:
          }
  
      }
docs: TODO - The 'verify' methods that follow are a basic ground work to guard against the invalid transition of job Batch Status / instance State.
  For now we are only disallowing updates once batch status or instance state are marked 'COMPLETED'/'ABANDONED'.
  <p>These checks could potentially be improved. E.g. <p><ul>
  <li>Should an job execution status ever transition from FAILED (except maybe to ABANDONED)?
  <li>In contrast a job instance needs to transition out of FAILED status during a RESTART.
  </ul><p>
  A limitation of this approach is that we're not leveraging DB locking like we do in the DB-based persistence. This is likely to end up
  providing just one more check rather than being continually developed as the basis of our status transition validation.