There are times when there may not be a "finished_time" field set on the return results of an API call to pulp's applicability API. 

This results in Katello's CV publish being stuck in the 'pending' state and is not the best way to determine if an API call is finished or not.

The better way is to use the status field of the API call and poll that to see if a task/call is complete.

IRC convo for context:

<jsherrill> mmccune: suspended is commong for remote tasks (like pulp tasks) when the task is sleeping waiting for it to finish in pulp
<jsherrill>   finish_time: 
<jsherrill> there's no finish_time!
<jsherrill> that's how we figure out if a task if actually finished or not
<mmccune> ahh
<jsherrill> rbarlow: applicability generation question ^
<jsherrill> why is finish_time blank on applicability_generatin ?
<jsherrill> generation*
<jsherrill> is that expected?
<rbarlow> hmmm, that isn't expected to me
<rbarlow> though, i would suggest against using finish_time to know if a task is finished
<rbarlow> i would recommend making a set of "final states" and checking to see if state is in that set
<rbarlow> things like failed, canceled, finished
<rbarlow> that mgiht be all of them
<jsherrill> rbarlow: yeha i'm not sure why we do
<rbarlow> actually i know a weird thing i did that might make finish time not always be present - if you cancel a task, it most often won't get a finish_time, but it will get one if its a sync or a publish
<rbarlow> it's implementation details
<mmccune> in this case, i didnt cancel
<rbarlow> and i was hoping to find time to fix that, but it didn't seem as important as other problems we've got right now ☺
<rbarlow> yeah i was just mentioning it so you knew that finish_time was a "best effort" and not a guarantee
<rbarlow> i would like to fix that
<rbarlow> but in the meantime, i'd suggest that it's probably better to use the task state anyway - that's what it's for
<jsherrill> rbarlow: yeah, mmccune mind filing an issue for that?
<mmccune> on it
<jsherrill> thanks