Conflicting triggers

Question

I'm still new to Salesforce and still can't grasp regarding triggers.

Scenario: My company's salesforce workspace has a managed package app installed. The managed package app has a custom trigger for Account: When account is updated, a job is added to a queueable job queue. I'm still checking the behavior of the managed app but it seems that 1 update transaction = 1 queueable job added.

Then I have another app (not yet listed in appexchange) created by a partner company. The process of the unlisted app is it runs a batch calling our partner's API and updating our records with the retrieved data. The unlisted app processes 200 records per transaction (Batch apex default behavior) and after 2-3 transactions, it would always fail. After checking the logs, I found out that after 2-3 update transactions, the queueable job queue overflows (limit afaik is 2). The managed package app is adding queueable jobs to the queue after every update.

I want to use both apps but can't think of a way to avoid the conflicting triggers.

My question is, if the unlisted app gets listed, will it stop triggering the other managed app's trigger during update?

Also if you have any other suggestions for implementation, I would really appreciate it.

EDIT

This is the error and log I am getting

caused by: System.LimitException: <<managed package app>> :Too many queueable jobs added to the queue: 2

Checking the logs, this what I get from the managed package app

10:02:10.997 (8997684279)|LIMIT_USAGE_FOR_NS|<<managed package app>>>| Number of SOQL queries: 0 out of 200 Number of query rows: 0 out of 50000 Number of SOSL queries: 0 out of 20 Number of DML statements: 0 out of 150 Number of DML rows: 0 out of 10000 Maximum CPU time: 0 out of 60000 Maximum heap size: 0 out of 12000000 Number of callouts: 0 out of 100 Number of Email Invocations: 0 out of 10 Number of future calls: 0 out of 0 Number of queueable jobs added to the queue: 2 out of 1 ******* CLOSE TO LIMIT Number of Mobile Apex push calls: 0 out of 10

TIA

Answer 1

This is a nastier manifestation of this issue, where a batch class (in your case, in Package A) performs record updates that cause triggers to fire (in Package B) that then attempt to enqueue Queueables. This issue will not be fixed by AppExchange listing or security review.

It's also unambiguously a bug in Package B. Their managed package code should be resilient against Batch Apex updating records in their package. The vendor should fix this problem with a package upgrade, because there's no guaranteed way to bypass it.

If the vendor provides a way to selectively disable their triggers, such as a Custom Setting, activating that suppression for the context user for your Batch Apex job would likely be a fix. However, far from all package vendors provide such a mechanism.

Another potential fix would be for Package A, your unlisted one, to run its batch jobs at batch size 1. That would massively reduce its record throughput and speed, and it only might solve the problem - it's pretty dependent on exactly how Package B's trigger or triggers work.

I would be pushing Package B's vendor for details on exactly what circumstances cause a Queueable to be fired. If there's any conditionality to it (i.e., we fire the Queueable only when record values look like X, Y, Z), that opens up other potential remedies.