The analysis_failed state was a relatively recent introduction to the set of image analysis states, which replaced the original behavior where an image analysis was simply retried over and over (returned to not_analyzed - initial state - on any failure). We changed that behavior early on, since it could create a condition where a lot of work could be happening even though the image couldn't be analyzed (for any of a number of reasons) in favor of the current behavior, where analysis_failed is its own state that can be handled explicitly. The suggestion I've made is in line with this model - the system wouldn't automatically retry analysis on failure, but it would retry analysis if an image is in analysis_failed state and another request to analyze the image was made explicitly by jenkins - in other words, we believe this is the right approach in general and would also we believe eliminate the need for a 'force' option in the jenkins plugin as an added benefit, and also would maintain current behavior where, if an image is already analyzed and jenkins asks for the image to be analyzed again, it amounts to a no-op on the service (where a force would cause it to go through heavy-weight analysis again even though it would yield the same result). Sounds like this is a good solution - we'll move ahead with adding that behavior to anchore-engine!
To your second question - when add a tag to the anchore-engine service for analysis, the service will look up the most recent image digest associated with that tag be querying the registry. If the digest is unchanged, then the system keeps the image in whatever state it is currently in (analyzed, analyzing, not_analyzed) and the new behavior would only flip the state from analysis_failed to not_analyzed to reset the analysis workflow. If the image digest associated with a tag is not in the anchore-engine database at the time of request to add an image to anchore-engine, then a new image record is created for the new digest and image analysis workflow begins. In other words, at any point in time, when one adds an image to anchore-engine using a tag identifier, the system attempts to get the most recent image digest associated with that tag and adds it to the system unless it is already present.
Note that this is the behavior for adding an image - when interacting with the anchore-engine service directly (via API of using the anchore-engine CLI, outside of jenkins) you can always 'get' any image that is known to anchore-engine by digest or imageId (to get specific reports for specific image content identified by digest or imageId), and if you 'get' an image from anchore-engine using a tag, then you will get back the most recent image digest/imageid data associated with that tag (that anchore-engine has stored).