Support jobs from called activities

[kevinmook]

What did we change?

Support jobs from called activities:

I also updated the error messages for when the processInstanceKey doesn't match. Previously the error looked like:

     Failure/Error:
       activate_job("notify_role").
         and_complete(task_id: task_id)

       expected: 2251799813686578
            got: 2251799813686595

       (compared using ==)

Now it looks like:

     Failure/Error:
       activate_job("notify_role").
         and_complete(task_id: task_id)

       expected the job's processInstanceKey ('2251799813686630') to match the process_instance_key ('2251799813686613')

Why are we doing this?

When a bpmn uses a "call activity" type, the processInstanceKey won't match the parent's processInstanceKey. This causes the activate_job helper to fail.

This adds an argument to activate_job to indicate that the job was created by a called activity.

Another workaround would be to set validate: false, but that would also prevent other helpful validations, like ensuring the job's type is correct.

Feedback on the argument name welcome, I'm happy to change it from "called" to something else if anyone has a better suggestion.

How was it tested?

• Specs
• Locally
• Staging

[rusterholz]

I love the intention here, but I'd like to see a clearer name for the new parameter -- and I think that might be best achieved if we also rename validate; see below.

[rusterholz]

I think putting unless called inside if validate might be a little confusing, both in terms of code structure and also for users of this API (since validate and called are bound in a non-obvious way).

What if we were to separate and rename both validate and called into new options that spell out exactly what they do and have sensible defaults? The validate option could perhaps be presence: true, and called: false could be main_instance: true, or something like that. Then there could be separate if presence and if main_instance blocks.