4

I have a managed application which I'm now trying to move to DX platform of development, but I'm getting an error of exceeding maximum storage:

Maximum size of request reached. Maximum size of request is 52428800 bytes

My app is approximately 80mb. I was trying to download it from Git, and then from IDE I generated a scratch org and tried pushing it.

Difficulty is, since it is big app, I can't isolate modules easily, since, it has objects, and those objects have lightning/vf button overrides and that implicitly includes referenced apex classes. So the code has to be pushed in one go.

How could we work in DX if it does not support apps larger than 50mb? Is there any viable workaround?

I found a Closed issue in CLI Git repository referencing exact same thing. And didn't understand why it should be closed: https://github.com/forcedotcom/cli/issues/109

There should be some arrangement for this kind of situation handling. From latest comment on the issue, there is a plugin, which I'm really grateful of, but it does not really integrate well with the flow. For example, I could do a first push to scratch org with that, but if my scratch org is changed to another and then I want to push static resources alone, then it does not detect the changes and always return blank list of resources for push to new scratch org.

Plus, what will happen if I want to change my static resource, but those are now in .forceignore file (as the necessity of using this plugin). So I uncomment them but still my changes are not detected.

Please someone guide me, how can we use the DX platform well considering it only supports apps smaller than 50mb right now? Any good work flows which I can use here as part of my development practices, please do mention them here.

Improve this question
3

If the large items are not intertwined components but opaque data such as static resources, then I suggest you replace those in your main Git repository with small place keepers e.g. replace the content of a 4M byte static resource with 4 bytes of content. You can then push that content in one go.

Then have the real static resources in a second Git repository (and if necessary third Git repository) and push that in as a separate step overwriting the place keeper content.

So start by finding out what the big components are, and hope it is not the intertwined ones.

PS

To keep all the components in one Git repository, probably better to have extra .forceignore files that you swap in and out for the two pushes.

Improve this answer
4
  • Separating repository into two sounds valid argument as an approach. Though a bit inconvenient :-), but at least it will let us keep historical data for updates, i was getting worried we won't be able to do that.Thanks for suggestions. But I really hope platform limit is either relaxed or this is handled better in CLI, if at possible. – VarunC Sep 21 '19 at 22:48
  • @VarunC Yeah, but the platform is littered with hard limits. It may be an underlying API not SFDX. You could post a request here github.com/forcedotcom/sfdx-core/issues. – Keith C Sep 22 '19 at 7:01
  • I agree. I think underlying api is imposing the limit. The Issue link I had posted in my ques, is exactly to point this out but sadly it is marked Closed. I don't know how to Re-open it. If we read the latest comment on the thread, it points us to a gr8 idea about how the CLI can overcome this by prioritizing Source Push components, which I believe should be good enough for it be reopened for consideration as an enhancement to CLI. – VarunC Sep 22 '19 at 11:27
  • @VarunC, I presume few people hit this so it is unlikely to reach the top of a priority list. – Keith C Sep 22 '19 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.