Resolved is not a 'close_state' - and you'll notice active is still = true, so OOTB it will only move forward with Closed (7) or Canceled (8). Out of curiosity, try manually changing active to false on a resolved one to see 1) if that sticks, or there could be a Business Rule to override that back to true, and 2) if it stays false, does that trigger the workflow. You don't want to mess up your incident process by making Resolved incidents inactive if that creates other problems like unable to re-open or update when they otherwise could for these few days until it is closed or auto-closes. The right way to do this if you want to make Resolved a close_state is to add it to the existing Dictionary Override Attributes on the State field for the incident table. You'll see something like this:
close_states=7;8,default_work_state=2,default_close_state=7,ignore_filter_on_new=true
If you don't want to mess with the Resolve state in the incident process, but want the workflow to move forward when it is resolved you may need something like a parallel wait for activity that is satisfied when the state changes to resolved. To get the workflow to recognize when this happens you would need a Business Rule or something that nudges/updates the sc_req_item record or whatever table the workflow is running on when an incident state changes to Resolved. Then you don't want the next activity to happen again when the incident changes to Closed, so you would delete that condition so that you only have a Condition for the incomplete result.
