Apex query rows limit reached according to log limit, but not sure about it

apexgovernorlimits

I have a LWC and I make a call to an apex method.

Depending on some filters, the queries return a different ammount of records, but on some scenarios, the limit of rows is reached, but the number of rows present on the limits info on the log doesn't match what the soql executions info outputs.
Example:

enter image description here

As you can see here, there are 4 soql queries (as the limit usage info says, correctly)
If you count the rows informed, there are 13,509 rows returned in total on that apex call.

That log has two limit usage sections:

enter image description here

I don't really understand why there are two sections (ERPvs is a namespace, I don't know if it refers to the package, not an expert on that matter)

For some reason, the info on ERPvs section outputs 53316 rows returned, when you can clearly see on the first image that there aren't even close to that number of rows returned. The confusing thing is , the log informs 4 SOQL queries (which is correct)…
Where are the other SOQL calls that returns the rest of the rows? If I understand correctly, the "per-transaction" limit should be to that apex call…
Am I missing something?

Before the last query I apply a limit calculation exactly to prevent this, but it doesn't work correctly it seems…

Integer queryLimit = Limits.getLimitQueryRows() >= Limits.getQueryRows() ? Limits.getLimitQueryRows() - Limits.getQueryRows() : 0;
    String qryLimit = queryLimit > 0 ? 'Limit '+ queryLimit : '';

    System.debug(LoggingLevel.DEBUG, 'query rows =====> ' + Limits.getQueryRows());

    System.debug('Query Productos ==========> '+ queryProducto + getQueryOrder() + qryLimit);
    List<Producto__c> productos = Database.query(queryProducto + getQueryOrder() + qryLimit);

The getQueryRows returns 28 before the last SOQL query….

Best Answer

ERPvs is a Managed Package, and as you can read more about in the docs here, it gets its own set of governor limits.

So, your code is not running into limits, but the managed package code is. You can try to play around with your code to see how that affects the number of queries in the managed package - maybe you don't need to be doing so much work in a single transaction on your end. If you need to be doing what you're doing, however, and uninstalling the package is not an option, you can try to reach out to the creators of the package and let them know this issue you're running into.