I have an HD app with an action block. On the first save of the HD, the action block calls a background logic block (this background LB is over a different table). In this background logic block, it needs to retrieve the HD’s detail records. I am finding that it can’t find the detail records and I am wondering if its because they haven’t been committed at this point. Is this expected behavior?
Yes, that is the expected behavior. And your reasoning is correct.
@brendan.b thank you! I tried using a shared temp table over the details in the action block and then fetching that in my background LB and it didn’t work. I want to confirm that is expected to?
Seconding @brendan.b 's answer.
I would also like to add an official caveat - it is an anti pattern and NOT recommended to call a background task during an action block or a trigger’s execution. Reason is that background task logic block is queued to the background, it is now completely outside of the transaction boundary. Whatever activity it performs is completely separate.
This means that if your save fails for whatever reason, but your background task logic block went off and wrote other records, those records will not be rolled back with the failure.
Yes, it doesn’t work because your background task logic block is now in it’s own transaction boundary and no longer has visibility into the transaction boundary (and it’s contents) where it was queued from.
It is expected that shared temp tables will not work across logic blocks from transaction → background like this.
For your use case, consider whether you can un-check the “Queue Immediately” checkbox when you use the Queue A Logic Block action to queue your background task. With that box un-checked, the LB won’t be queued until the first transaction completes successfully. This gains you two potential benefits:
- The information from the first transaction is now committed and Live, so your background logic block can access it.
- You avoid the data integrity concerns that Cheyanne raised.