@kevinearls we had a similar problem in e2e tests before. Unfortunately, there are no unit tests that can be made to check this new code, but perhaps you could adapt the test that was failing before? It's actually easy to reproduce. This is a CR that will trigger the condition where the operator will wait indefinitely:

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: fails
spec:
  allInOne:
    options:
      invalidOption: "invalid option"

Apply this, wait a few milliseconds and delete the CR. Before this PR, the reconciliation would fail after 5 minutes with:

ERRO[0317] failed to apply the changes                   error="timed out waiting for the condition" execution="2019-09-24 09:16:52.72172503 +0000 UTC" instance=fails namespace=default

With this PR, it fails far earlier with:

WARN[0012] Deployment has been removed.                  name=fails namespace=default
ERRO[0012] failed to apply the changes                   error="deployment has been removed" execution="2019-09-24 09:22:28.740323219 +0000 UTC" instance=fails namespace=default

@jkandasa, I published an image that can be used for manual testing this change: quay.io/jpkroehling/jaeger-operator:670-Recognize-when-deployment-has-been-deleted.

@jpkrohling sorry for the delay, I will be working on this today.

@jpkrohling Bizarrely, I cannot reproduce this now. I may be overlooking something, or it may just be that whatever timing issue I was hitting before is not occurring now. I will try again later when I have time, but it might be best to wait till @jkandasa is back.

@jpkrohling I was able to confirm that your CR triggers the condition, and that this PR fixes it. So LGTM.

Thanks! Do you think it makes sense to create an e2e test for this? If so, could you create an issue for that? I'm merging this in the meantime.