Created attachment 959503 [details]
A snippet from /var/log/foreman/production.log showing a DELETE, GET and GET request

Description of problem:
Deleting a repository is an asynchronous task, and there's no way to monitor the progress of the deletion except by polling to see if that repository still exists. This is problematic, and it's exacerbated by the fact that the task can take a significant (10+ seconds) amount of time. When a client deletes a repository, Satellite should either block until the deletion is done, or it should return a task that can be monitored.

Version-Release number of selected component (if applicable):
Tested against a machine running a nightly version of Foreman 1.8.0-develop, with the following packages installed:

* candlepin-0.9.34-1.el7.noarch
* candlepin-common-1.0.14-1.el7.noarch
* candlepin-selinux-0.9.34-1.el7.noarch
* candlepin-tomcat-0.9.34-1.el7.noarch
* elasticsearch-0.90.10-7.el7.noarch
* foreman-1.8.0-0.develop.201411201054gitbe4602e.el7.noarch
* foreman-compute-1.8.0-0.develop.201411201054gitbe4602e.el7.noarch
* foreman-gce-1.8.0-0.develop.201411201054gitbe4602e.el7.noarch
* foreman-libvirt-1.8.0-0.develop.201411201054gitbe4602e.el7.noarch
* foreman-ovirt-1.8.0-0.develop.201411201054gitbe4602e.el7.noarch
* foreman-postgresql-1.8.0-0.develop.201411201054gitbe4602e.el7.noarch
* foreman-proxy-1.8.0-0.develop.201411121327gitab6edc2.el7.noarch
* foreman-release-1.8.0-0.develop.201411201054gitbe4602e.el7.noarch
* foreman-selinux-1.8.0-0.develop.201410280941git10de1c5.el7.noarch
* foreman-vmware-1.8.0-0.develop.201411201054gitbe4602e.el7.noarch
* katello-2.1.0-1.201411061509gitb0b8f43.el7.noarch
* katello-certs-tools-2.0.1-1.el7.noarch
* katello-default-ca-1.0-1.noarch
* katello-installer-2.1.0-1.201411172212git9d6f424.el7.noarch
* katello-repos-2.1.1-1.el7.noarch
* katello-server-ca-1.0-1.noarch
* openldap-2.4.39-3.el7.x86_64
* pulp-docker-plugins-0.2.1-0.2.beta.el7.noarch
* pulp-katello-0.3-3.el7.noarch
* pulp-nodes-common-2.5.0-0.7.beta.el7.noarch
* pulp-nodes-parent-2.5.0-0.7.beta.el7.noarch
* pulp-puppet-plugins-2.5.0-0.7.beta.el7.noarch
* pulp-puppet-tools-2.5.0-0.7.beta.el7.noarch
* pulp-rpm-plugins-2.5.0-0.7.beta.el7.noarch
* pulp-selinux-2.5.0-0.7.beta.el7.noarch
* pulp-server-2.5.0-0.7.beta.el7.noarch
* python-ldap-2.4.6-6.el7.x86_64
* ruby193-rubygem-ldap_fluff-0.3.3-1.el7.noarch
* ruby193-rubygem-net-ldap-0.3.1-2.el7.noarch
* ruby193-rubygem-runcible-1.3.0-1.el7.noarch

How reproducible:
Very frequent, but varies depending on server load.

Steps to Reproduce:
1. Create (POST) a repository and take note of its ID.
2. DELETE that repository.
3. GET that repository. Check the contents of the response.

Actual results:
Either an HTTP 200 or HTTP 500 response. Immediately after the deletion, an HTTP 200 response is received, which indicates that the repository still exists. After the deletion process starts, an HTTP 500 response is received with the following error message:

    undefined method `[]' for nil:NilClass

Expected results:
An HTTP 404.

Additional info:
Here's a simple script that I've used to test this issue (it depends on some robottelo code):

    #!/usr/bin/env python2
    from robottelo.entities import Repository
    from time import sleep
    repo_id = Repository().create_json()['id']
    repo = Repository(id=repo_id)
    print('Target: 200, actual: {0}'.format(repo.read_raw().status_code))
    repo.delete()
    print('Target: 404, actual: {0}'.format(repo.read_raw().status_code))
    sleep(10)
    print('Target: 404, actual: {0}'.format(repo.read_raw().status_code))

And here's some output I've received:

    Target: 200, actual: 200
    Target: 404, actual: 200
    Target: 404, actual: 500