`contact-already-on-job` condition can block valid actions

Actions using the contact-already-on-job condition can fail incorrectly when the job originally had a contact in a role, and a different unique contact is later added to that same role before the trigger fires.

Expected behavior: if the condition is true at the time the trigger runs, the action should send.

Current behavior: the action can fail even when the contact change was made before the trigger time.

Example order: inspection 1008590531

---

Clarifications to capture when reproducing

• Document how the flow uses the attribute: e.g. contact-already-on-job is_false (only send when not duplicate) vs is_true, and what “blocked” means in practice (condition wrong way, message skipped, Bull filtered, etc.).

Implementation notes

• Evaluation path: attributePathResolver → contact-already-on-job → resolveContactIdentity, using inspection.people or _conditionScopePeople when set.
• Existing unit tests cover same contact on two roles (duplicate) and recipient-scoped checks; they do not cover role replacement (contact A replaced by distinct contact B on the same role).

Repro narrative (data shape)

• Before: Contact A on role R.
• After: Contact B on role R (clarify whether A is removed or remains elsewhere).
• At trigger time: Expected one “current” assignment for R with two distinct contact identities across the job → duplicate condition should be false if the intent is “no duplicate person on the job.”
• Actual: Condition still indicates duplicate / action still blocked — specify which.

Hypotheses for investigation

1. Stale people or wrong _conditionScopePeople after contact update so evaluation sees an intermediate or duplicate snapshot.
2. Two different contacts colliding to the same identity key in resolveContactIdentity (e.g. missing email/phone edge cases).
3. Interaction with recipient-scoped evaluation or action timing — see related ATT-1381 (grouping / when payload is built).

Suggested acceptance criteria

• Backend regression test: role R had A, then B only on R (or documented end state); no duplicate identity; condition result matches product intent.
• Manual verification on the example inspection or a cloned scenario.

Related

• ATT-1381 — may matter if evaluation runs against a stale or partial payload.

Transcript Context

The Southwest team clarified that tag-based action flow conditions are currently too recipient-specific. Their example was a VIP agent tag that should trigger an office-facing email when any contact on the job has that tag, but the email does not fire because the condition only evaluates against the email recipient. They want tag-based conditions to support a broader job-level mode, such as applying when any contact on the job has the tag, instead of only when the recipient has it.

The team discussed this as a product gap in how action flow conditions are scoped, not just a one-off configuration problem.