The 50,000 row query limit is not actually a “per APEX call” as widely believedHow to turn boxcarring OFF for LWC imperative apex method calls?Maximum number of records retrieved by one SOQL query in a lightning Apex backend controller50,000 query row governor limitDoes the query cursor limit matter if I'm only returning a single row?Apex governor limit warning emailsWhy does it say my SOQL for loop returned 50,001 records when it broke the loop after 20k?Design practises against 50,000 row limitFirst error: Too many query rows: 50001 in a batch apex class without any inner queryAggregated Query Too many query rowsToo many query rows: 50001 in export csvWhat are the limitations of number of Rows that can be returned in an Aura Enabled APEX Method?refreshApex in LWC not working outside of Apex method call promise?
The 50,000 row query limit is not actually a "per APEX call" as widely believed
Is it possible to eat quietly in Minecraft?
What would be the side effects on the life of a person becoming indestructible?
Can a character with a low Intelligence score take the Ritual Caster feat and choose the Wizard class?
How do changes to your speed that occur on your own turn affect your available movement?
Raw curve25519 public key points
Short story where a flexible reality hardens to an unchanging one
Extrapolation v. Interpolation
Can 々 stand for a duplicated kanji with a different reading?
Considerations when providing money to one child now, and the other later?
Bug in Lualatex: not printing characters from calculation
How important is a good quality camera for good photography?
Short story about a group of sci-fi writers sitting around discussing their profession
What happens when two cards both modify what I'm allowed to do?
How can I make sure my players' decisions have consequences?
How can the artificial womb be made affordable for the common people?
what to say when a company asks you why someone (a friend) who was fired left?
Historicity doubted by Romans
How can I tell if there was a power cut when I was out?
Can't understand how static works exactly
Monty Hall Problem with a Fallible Monty
Span command across LaTeX environments
Using paddles to support a bug net
How can I deal with someone that wants to kill something that isn't supposed to be killed?
The 50,000 row query limit is not actually a “per APEX call” as widely believed
How to turn boxcarring OFF for LWC imperative apex method calls?Maximum number of records retrieved by one SOQL query in a lightning Apex backend controller50,000 query row governor limitDoes the query cursor limit matter if I'm only returning a single row?Apex governor limit warning emailsWhy does it say my SOQL for loop returned 50,001 records when it broke the loop after 20k?Design practises against 50,000 row limitFirst error: Too many query rows: 50001 in a batch apex class without any inner queryAggregated Query Too many query rowsToo many query rows: 50001 in export csvWhat are the limitations of number of Rows that can be returned in an Aura Enabled APEX Method?refreshApex in LWC not working outside of Apex method call promise?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
I recently ran into a strange issue with the 50,000 row query limit that had me puzzled due to the belief that the 50,000 row query limit applied only per-call.
This realization occurred while writing a LWC where the .js
file calls apex methods to gather data. Specifically, in this instance, I was creating a custom table that displays some aggregated data and only loads and displays 5 rows at time. Users can page through the table to load and display 5 more items.
Whenever I am loading a table page, the JS side makes 5 separate calls (one for each row) to the same APEX method to gather all the aggregated data. I actually use a Promise to send off all 5 calls at one time.
Inside of this reused APEX method is a few queries that get about 2500
rows combined MAX. This apex method does not query over 2500 rows per-call in any case
.
When JS uses a promise to send off 5 of these calls at once, I have no problem. However, I also allow users to download the entire table into a csv. When they hit this button, JS uses the same APEX method to load the data, but this part requires JS to put more than 5 calls to the same method in the Promise that gathers all the data. If the table is 10 pages, it ends up putting 50 calls to the same APEX method in the same promise. This is when I get the 50,000 query limit reached
error.
This has me confused because I thought that a single call to an APEX method can't query over 50,000 rows
... After playing around a little, I noticed that the error would occur once I tried to load more than 20 rows. 19 rows worked fine because 19 * 2500 < 50,000. But 21 rows errored because 21* 2500 > 50,000.
Therefore, I believe that the 50,000 query limit isn't calculated per APEX Method call, but rather calculated on the total number of simultaneous calls to the same APEX method.
query lightning-web-components governorlimits
add a comment |
I recently ran into a strange issue with the 50,000 row query limit that had me puzzled due to the belief that the 50,000 row query limit applied only per-call.
This realization occurred while writing a LWC where the .js
file calls apex methods to gather data. Specifically, in this instance, I was creating a custom table that displays some aggregated data and only loads and displays 5 rows at time. Users can page through the table to load and display 5 more items.
Whenever I am loading a table page, the JS side makes 5 separate calls (one for each row) to the same APEX method to gather all the aggregated data. I actually use a Promise to send off all 5 calls at one time.
Inside of this reused APEX method is a few queries that get about 2500
rows combined MAX. This apex method does not query over 2500 rows per-call in any case
.
When JS uses a promise to send off 5 of these calls at once, I have no problem. However, I also allow users to download the entire table into a csv. When they hit this button, JS uses the same APEX method to load the data, but this part requires JS to put more than 5 calls to the same method in the Promise that gathers all the data. If the table is 10 pages, it ends up putting 50 calls to the same APEX method in the same promise. This is when I get the 50,000 query limit reached
error.
This has me confused because I thought that a single call to an APEX method can't query over 50,000 rows
... After playing around a little, I noticed that the error would occur once I tried to load more than 20 rows. 19 rows worked fine because 19 * 2500 < 50,000. But 21 rows errored because 21* 2500 > 50,000.
Therefore, I believe that the 50,000 query limit isn't calculated per APEX Method call, but rather calculated on the total number of simultaneous calls to the same APEX method.
query lightning-web-components governorlimits
5
It's 50k per transaction. Salesforce is probably bundling all these requests into 1 transaction.
– Programmatic
8 hours ago
1
See this answer from sfdcfox. It's Lightning's boxcarring behavior grouping the server calls into one transaction.
– David Reed♦
8 hours ago
2
@DavidReed Ah, that moment when you quote an answer of mine when I'm writing an answer of mine.
– sfdcfox
8 hours ago
2
@sfdcfox , DavidReed answerception.
– Pranay Jaiswal
8 hours ago
add a comment |
I recently ran into a strange issue with the 50,000 row query limit that had me puzzled due to the belief that the 50,000 row query limit applied only per-call.
This realization occurred while writing a LWC where the .js
file calls apex methods to gather data. Specifically, in this instance, I was creating a custom table that displays some aggregated data and only loads and displays 5 rows at time. Users can page through the table to load and display 5 more items.
Whenever I am loading a table page, the JS side makes 5 separate calls (one for each row) to the same APEX method to gather all the aggregated data. I actually use a Promise to send off all 5 calls at one time.
Inside of this reused APEX method is a few queries that get about 2500
rows combined MAX. This apex method does not query over 2500 rows per-call in any case
.
When JS uses a promise to send off 5 of these calls at once, I have no problem. However, I also allow users to download the entire table into a csv. When they hit this button, JS uses the same APEX method to load the data, but this part requires JS to put more than 5 calls to the same method in the Promise that gathers all the data. If the table is 10 pages, it ends up putting 50 calls to the same APEX method in the same promise. This is when I get the 50,000 query limit reached
error.
This has me confused because I thought that a single call to an APEX method can't query over 50,000 rows
... After playing around a little, I noticed that the error would occur once I tried to load more than 20 rows. 19 rows worked fine because 19 * 2500 < 50,000. But 21 rows errored because 21* 2500 > 50,000.
Therefore, I believe that the 50,000 query limit isn't calculated per APEX Method call, but rather calculated on the total number of simultaneous calls to the same APEX method.
query lightning-web-components governorlimits
I recently ran into a strange issue with the 50,000 row query limit that had me puzzled due to the belief that the 50,000 row query limit applied only per-call.
This realization occurred while writing a LWC where the .js
file calls apex methods to gather data. Specifically, in this instance, I was creating a custom table that displays some aggregated data and only loads and displays 5 rows at time. Users can page through the table to load and display 5 more items.
Whenever I am loading a table page, the JS side makes 5 separate calls (one for each row) to the same APEX method to gather all the aggregated data. I actually use a Promise to send off all 5 calls at one time.
Inside of this reused APEX method is a few queries that get about 2500
rows combined MAX. This apex method does not query over 2500 rows per-call in any case
.
When JS uses a promise to send off 5 of these calls at once, I have no problem. However, I also allow users to download the entire table into a csv. When they hit this button, JS uses the same APEX method to load the data, but this part requires JS to put more than 5 calls to the same method in the Promise that gathers all the data. If the table is 10 pages, it ends up putting 50 calls to the same APEX method in the same promise. This is when I get the 50,000 query limit reached
error.
This has me confused because I thought that a single call to an APEX method can't query over 50,000 rows
... After playing around a little, I noticed that the error would occur once I tried to load more than 20 rows. 19 rows worked fine because 19 * 2500 < 50,000. But 21 rows errored because 21* 2500 > 50,000.
Therefore, I believe that the 50,000 query limit isn't calculated per APEX Method call, but rather calculated on the total number of simultaneous calls to the same APEX method.
query lightning-web-components governorlimits
query lightning-web-components governorlimits
asked 8 hours ago
BlondeSwanBlondeSwan
38912 bronze badges
38912 bronze badges
5
It's 50k per transaction. Salesforce is probably bundling all these requests into 1 transaction.
– Programmatic
8 hours ago
1
See this answer from sfdcfox. It's Lightning's boxcarring behavior grouping the server calls into one transaction.
– David Reed♦
8 hours ago
2
@DavidReed Ah, that moment when you quote an answer of mine when I'm writing an answer of mine.
– sfdcfox
8 hours ago
2
@sfdcfox , DavidReed answerception.
– Pranay Jaiswal
8 hours ago
add a comment |
5
It's 50k per transaction. Salesforce is probably bundling all these requests into 1 transaction.
– Programmatic
8 hours ago
1
See this answer from sfdcfox. It's Lightning's boxcarring behavior grouping the server calls into one transaction.
– David Reed♦
8 hours ago
2
@DavidReed Ah, that moment when you quote an answer of mine when I'm writing an answer of mine.
– sfdcfox
8 hours ago
2
@sfdcfox , DavidReed answerception.
– Pranay Jaiswal
8 hours ago
5
5
It's 50k per transaction. Salesforce is probably bundling all these requests into 1 transaction.
– Programmatic
8 hours ago
It's 50k per transaction. Salesforce is probably bundling all these requests into 1 transaction.
– Programmatic
8 hours ago
1
1
See this answer from sfdcfox. It's Lightning's boxcarring behavior grouping the server calls into one transaction.
– David Reed♦
8 hours ago
See this answer from sfdcfox. It's Lightning's boxcarring behavior grouping the server calls into one transaction.
– David Reed♦
8 hours ago
2
2
@DavidReed Ah, that moment when you quote an answer of mine when I'm writing an answer of mine.
– sfdcfox
8 hours ago
@DavidReed Ah, that moment when you quote an answer of mine when I'm writing an answer of mine.
– sfdcfox
8 hours ago
2
2
@sfdcfox , DavidReed answerception.
– Pranay Jaiswal
8 hours ago
@sfdcfox , DavidReed answerception.
– Pranay Jaiswal
8 hours ago
add a comment |
2 Answers
2
active
oldest
votes
Aura, and LWC, groups several requests together in order to maximize performance. This is called "boxcar'ing" (or boxcarring) in the documentation. All Apex requests in the same boxcar payload are subject to a single set of governor limits, even though they're allowed to fail/succeed independently. This means you need to make sure you don't place DML before callout operation requests, and you'll want to limit the number of requests you perform simultaneously. This is documented behavior and has existed since the beginning of Lightning.
Interesting. Up until now, everything I've read about the 50,000 query limit suggests it's per-call. I've never read about Lighting "boxcaring" until now. thanks
– BlondeSwan
8 hours ago
1
@BlondeSwan I think its from VF days. It was called as buffer in remoting .Whether to group requests executed close to each other in time into a single request. The default is true.
– Pranay Jaiswal
8 hours ago
3
In a call I had with one of the Salesforce Product Managers (responsible for LWC boxcarring) where I was asking about the ability to turn off boxcarring IN LWC (no, you can't and there's nothing yet on the cards), she admitted that the limit being applied across all the requests in the boxcarred chain is a bug that they are looking to fix (usual "forward statement" declaration applies). Once fixed, each request will have its own independent limits again.
– Phil W
8 hours ago
@PhilW Good to know. I always felt it was a bug (undocumented behavior). At least they know about it.
– sfdcfox
8 hours ago
add a comment |
Its called as boxcarring, Salesforce bundles multiple request in to 1 to save repeated calls to server.
You can seee from Debug logs, only one is created.
A quick solution is to add a timeout or use the promise chain while calling apex. In this way , each apex call will be treated as new transaction and those limits get reset.
new Promise(function(resolve, reject)
setTimeout(() => resolve(1), 1000); // (*)
).then(function(result) // (**)
alert(result); // 1
return result * 2;
).then(function(result) // (***)
alert(result); // 2
return result * 2;
).then(function(result)
alert(result); // 4
return result * 2;
);
Box carring also has side-effect of slowing initial loading down. read more here.
There's a lot of discussion about staggering the requests by introducing various delays elsewhere on SFSE where the conclusion was it more-or-less worked but could require significantly long delays (of the order of half a second) in order to avoid boxcarring.
– Phil W
8 hours ago
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "459"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f270842%2fthe-50-000-row-query-limit-is-not-actually-a-per-apex-call-as-widely-believed%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Aura, and LWC, groups several requests together in order to maximize performance. This is called "boxcar'ing" (or boxcarring) in the documentation. All Apex requests in the same boxcar payload are subject to a single set of governor limits, even though they're allowed to fail/succeed independently. This means you need to make sure you don't place DML before callout operation requests, and you'll want to limit the number of requests you perform simultaneously. This is documented behavior and has existed since the beginning of Lightning.
Interesting. Up until now, everything I've read about the 50,000 query limit suggests it's per-call. I've never read about Lighting "boxcaring" until now. thanks
– BlondeSwan
8 hours ago
1
@BlondeSwan I think its from VF days. It was called as buffer in remoting .Whether to group requests executed close to each other in time into a single request. The default is true.
– Pranay Jaiswal
8 hours ago
3
In a call I had with one of the Salesforce Product Managers (responsible for LWC boxcarring) where I was asking about the ability to turn off boxcarring IN LWC (no, you can't and there's nothing yet on the cards), she admitted that the limit being applied across all the requests in the boxcarred chain is a bug that they are looking to fix (usual "forward statement" declaration applies). Once fixed, each request will have its own independent limits again.
– Phil W
8 hours ago
@PhilW Good to know. I always felt it was a bug (undocumented behavior). At least they know about it.
– sfdcfox
8 hours ago
add a comment |
Aura, and LWC, groups several requests together in order to maximize performance. This is called "boxcar'ing" (or boxcarring) in the documentation. All Apex requests in the same boxcar payload are subject to a single set of governor limits, even though they're allowed to fail/succeed independently. This means you need to make sure you don't place DML before callout operation requests, and you'll want to limit the number of requests you perform simultaneously. This is documented behavior and has existed since the beginning of Lightning.
Interesting. Up until now, everything I've read about the 50,000 query limit suggests it's per-call. I've never read about Lighting "boxcaring" until now. thanks
– BlondeSwan
8 hours ago
1
@BlondeSwan I think its from VF days. It was called as buffer in remoting .Whether to group requests executed close to each other in time into a single request. The default is true.
– Pranay Jaiswal
8 hours ago
3
In a call I had with one of the Salesforce Product Managers (responsible for LWC boxcarring) where I was asking about the ability to turn off boxcarring IN LWC (no, you can't and there's nothing yet on the cards), she admitted that the limit being applied across all the requests in the boxcarred chain is a bug that they are looking to fix (usual "forward statement" declaration applies). Once fixed, each request will have its own independent limits again.
– Phil W
8 hours ago
@PhilW Good to know. I always felt it was a bug (undocumented behavior). At least they know about it.
– sfdcfox
8 hours ago
add a comment |
Aura, and LWC, groups several requests together in order to maximize performance. This is called "boxcar'ing" (or boxcarring) in the documentation. All Apex requests in the same boxcar payload are subject to a single set of governor limits, even though they're allowed to fail/succeed independently. This means you need to make sure you don't place DML before callout operation requests, and you'll want to limit the number of requests you perform simultaneously. This is documented behavior and has existed since the beginning of Lightning.
Aura, and LWC, groups several requests together in order to maximize performance. This is called "boxcar'ing" (or boxcarring) in the documentation. All Apex requests in the same boxcar payload are subject to a single set of governor limits, even though they're allowed to fail/succeed independently. This means you need to make sure you don't place DML before callout operation requests, and you'll want to limit the number of requests you perform simultaneously. This is documented behavior and has existed since the beginning of Lightning.
edited 8 hours ago
Phil W
2,4851 gold badge3 silver badges12 bronze badges
2,4851 gold badge3 silver badges12 bronze badges
answered 8 hours ago
sfdcfoxsfdcfox
279k14 gold badges227 silver badges479 bronze badges
279k14 gold badges227 silver badges479 bronze badges
Interesting. Up until now, everything I've read about the 50,000 query limit suggests it's per-call. I've never read about Lighting "boxcaring" until now. thanks
– BlondeSwan
8 hours ago
1
@BlondeSwan I think its from VF days. It was called as buffer in remoting .Whether to group requests executed close to each other in time into a single request. The default is true.
– Pranay Jaiswal
8 hours ago
3
In a call I had with one of the Salesforce Product Managers (responsible for LWC boxcarring) where I was asking about the ability to turn off boxcarring IN LWC (no, you can't and there's nothing yet on the cards), she admitted that the limit being applied across all the requests in the boxcarred chain is a bug that they are looking to fix (usual "forward statement" declaration applies). Once fixed, each request will have its own independent limits again.
– Phil W
8 hours ago
@PhilW Good to know. I always felt it was a bug (undocumented behavior). At least they know about it.
– sfdcfox
8 hours ago
add a comment |
Interesting. Up until now, everything I've read about the 50,000 query limit suggests it's per-call. I've never read about Lighting "boxcaring" until now. thanks
– BlondeSwan
8 hours ago
1
@BlondeSwan I think its from VF days. It was called as buffer in remoting .Whether to group requests executed close to each other in time into a single request. The default is true.
– Pranay Jaiswal
8 hours ago
3
In a call I had with one of the Salesforce Product Managers (responsible for LWC boxcarring) where I was asking about the ability to turn off boxcarring IN LWC (no, you can't and there's nothing yet on the cards), she admitted that the limit being applied across all the requests in the boxcarred chain is a bug that they are looking to fix (usual "forward statement" declaration applies). Once fixed, each request will have its own independent limits again.
– Phil W
8 hours ago
@PhilW Good to know. I always felt it was a bug (undocumented behavior). At least they know about it.
– sfdcfox
8 hours ago
Interesting. Up until now, everything I've read about the 50,000 query limit suggests it's per-call. I've never read about Lighting "boxcaring" until now. thanks
– BlondeSwan
8 hours ago
Interesting. Up until now, everything I've read about the 50,000 query limit suggests it's per-call. I've never read about Lighting "boxcaring" until now. thanks
– BlondeSwan
8 hours ago
1
1
@BlondeSwan I think its from VF days. It was called as buffer in remoting .
Whether to group requests executed close to each other in time into a single request. The default is true.
– Pranay Jaiswal
8 hours ago
@BlondeSwan I think its from VF days. It was called as buffer in remoting .
Whether to group requests executed close to each other in time into a single request. The default is true.
– Pranay Jaiswal
8 hours ago
3
3
In a call I had with one of the Salesforce Product Managers (responsible for LWC boxcarring) where I was asking about the ability to turn off boxcarring IN LWC (no, you can't and there's nothing yet on the cards), she admitted that the limit being applied across all the requests in the boxcarred chain is a bug that they are looking to fix (usual "forward statement" declaration applies). Once fixed, each request will have its own independent limits again.
– Phil W
8 hours ago
In a call I had with one of the Salesforce Product Managers (responsible for LWC boxcarring) where I was asking about the ability to turn off boxcarring IN LWC (no, you can't and there's nothing yet on the cards), she admitted that the limit being applied across all the requests in the boxcarred chain is a bug that they are looking to fix (usual "forward statement" declaration applies). Once fixed, each request will have its own independent limits again.
– Phil W
8 hours ago
@PhilW Good to know. I always felt it was a bug (undocumented behavior). At least they know about it.
– sfdcfox
8 hours ago
@PhilW Good to know. I always felt it was a bug (undocumented behavior). At least they know about it.
– sfdcfox
8 hours ago
add a comment |
Its called as boxcarring, Salesforce bundles multiple request in to 1 to save repeated calls to server.
You can seee from Debug logs, only one is created.
A quick solution is to add a timeout or use the promise chain while calling apex. In this way , each apex call will be treated as new transaction and those limits get reset.
new Promise(function(resolve, reject)
setTimeout(() => resolve(1), 1000); // (*)
).then(function(result) // (**)
alert(result); // 1
return result * 2;
).then(function(result) // (***)
alert(result); // 2
return result * 2;
).then(function(result)
alert(result); // 4
return result * 2;
);
Box carring also has side-effect of slowing initial loading down. read more here.
There's a lot of discussion about staggering the requests by introducing various delays elsewhere on SFSE where the conclusion was it more-or-less worked but could require significantly long delays (of the order of half a second) in order to avoid boxcarring.
– Phil W
8 hours ago
add a comment |
Its called as boxcarring, Salesforce bundles multiple request in to 1 to save repeated calls to server.
You can seee from Debug logs, only one is created.
A quick solution is to add a timeout or use the promise chain while calling apex. In this way , each apex call will be treated as new transaction and those limits get reset.
new Promise(function(resolve, reject)
setTimeout(() => resolve(1), 1000); // (*)
).then(function(result) // (**)
alert(result); // 1
return result * 2;
).then(function(result) // (***)
alert(result); // 2
return result * 2;
).then(function(result)
alert(result); // 4
return result * 2;
);
Box carring also has side-effect of slowing initial loading down. read more here.
There's a lot of discussion about staggering the requests by introducing various delays elsewhere on SFSE where the conclusion was it more-or-less worked but could require significantly long delays (of the order of half a second) in order to avoid boxcarring.
– Phil W
8 hours ago
add a comment |
Its called as boxcarring, Salesforce bundles multiple request in to 1 to save repeated calls to server.
You can seee from Debug logs, only one is created.
A quick solution is to add a timeout or use the promise chain while calling apex. In this way , each apex call will be treated as new transaction and those limits get reset.
new Promise(function(resolve, reject)
setTimeout(() => resolve(1), 1000); // (*)
).then(function(result) // (**)
alert(result); // 1
return result * 2;
).then(function(result) // (***)
alert(result); // 2
return result * 2;
).then(function(result)
alert(result); // 4
return result * 2;
);
Box carring also has side-effect of slowing initial loading down. read more here.
Its called as boxcarring, Salesforce bundles multiple request in to 1 to save repeated calls to server.
You can seee from Debug logs, only one is created.
A quick solution is to add a timeout or use the promise chain while calling apex. In this way , each apex call will be treated as new transaction and those limits get reset.
new Promise(function(resolve, reject)
setTimeout(() => resolve(1), 1000); // (*)
).then(function(result) // (**)
alert(result); // 1
return result * 2;
).then(function(result) // (***)
alert(result); // 2
return result * 2;
).then(function(result)
alert(result); // 4
return result * 2;
);
Box carring also has side-effect of slowing initial loading down. read more here.
answered 8 hours ago
Pranay JaiswalPranay Jaiswal
22.7k5 gold badges33 silver badges74 bronze badges
22.7k5 gold badges33 silver badges74 bronze badges
There's a lot of discussion about staggering the requests by introducing various delays elsewhere on SFSE where the conclusion was it more-or-less worked but could require significantly long delays (of the order of half a second) in order to avoid boxcarring.
– Phil W
8 hours ago
add a comment |
There's a lot of discussion about staggering the requests by introducing various delays elsewhere on SFSE where the conclusion was it more-or-less worked but could require significantly long delays (of the order of half a second) in order to avoid boxcarring.
– Phil W
8 hours ago
There's a lot of discussion about staggering the requests by introducing various delays elsewhere on SFSE where the conclusion was it more-or-less worked but could require significantly long delays (of the order of half a second) in order to avoid boxcarring.
– Phil W
8 hours ago
There's a lot of discussion about staggering the requests by introducing various delays elsewhere on SFSE where the conclusion was it more-or-less worked but could require significantly long delays (of the order of half a second) in order to avoid boxcarring.
– Phil W
8 hours ago
add a comment |
Thanks for contributing an answer to Salesforce Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f270842%2fthe-50-000-row-query-limit-is-not-actually-a-per-apex-call-as-widely-believed%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
5
It's 50k per transaction. Salesforce is probably bundling all these requests into 1 transaction.
– Programmatic
8 hours ago
1
See this answer from sfdcfox. It's Lightning's boxcarring behavior grouping the server calls into one transaction.
– David Reed♦
8 hours ago
2
@DavidReed Ah, that moment when you quote an answer of mine when I'm writing an answer of mine.
– sfdcfox
8 hours ago
2
@sfdcfox , DavidReed answerception.
– Pranay Jaiswal
8 hours ago