Orchestrator odd behavior (at least to me) for Postponed Queue Item and its Trigger (v2020.10.5)

We are running Orchestrator 2020.10.5.

I’m running a test with some new logic and noticing some odd Orchestrator behavior (to me its odd). We have two queues setup and each queue has a Queue Based Trigger associated with it.

One queue is for Eastern TZ and the other is for Central TZ. Our transaction items all come in with Postponed times set on them.

For testing, what we usually do is set of the Postponed date to be in the past and the postponed-in-past transaction items will trigger essentially acting like “run now” transaction items but not always. That is what I’m noticing for the odd behavior.

What just happened is this:

  • I created two transaction items in the Central TZ queue and both triggered as their postponed date is in the past.
  • I created third transaction item in the Eastern TZ queue and it did not triggered even with a postponed date in the past.

I know there is a 30-minute background thread/service which scans for NEW transaction items and it should pickup up that third transaction item (but even then I not 100% convinced this works as intended).

Does anyone know why that third postponed-in-the-past transaction item did not trigger but the first two did ?


Another question to this is why are we not seeing “Pending” jobs showing up ?

The Queue Based Triggers are all setup for 15 max jobs. But we never see “Pending” jobs.

We use Postponed dates on our transaction Items. Typically the Postponed date is set to the same date/time for multiple transaction items.

Hi @riverrat437

Given that this looks to be an issue with an on-premise Orchestrator installation, would you mind contacting our technical support to help you debug this issue? It might be easier to find out what goes wrong this way:

1 Like