You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a daml package is very large, it can cause problems for clients that have to block processing to download and parse it. Ideally application logic should be split into independent, modular components, which can exist in separate packages.
What is the solution you would propose?
Have the daml compiler issue a warning when the resultant dar is excessively large. The message could link to documentation describing how to split packages up, and discussing the rationale for doing so.
The threshold size is TBD, but could perhaps be configurable.
Describe alternatives you've considered
Status quo
We have observed that over time packages can grow larger incrementally, and cause progressively more problems for tooling and clients.
Warning at the UploadDarFile stage
This could be done as well, but is later in the process. The daml build is the earliest stage at which we can determine the package size.
Additional context
There has been discussion of setting the max-inbound-message-size for GRPC to be a very high value in ledger clients we build, so that we don't get unexpected failures when issuing rpc's like GetPackage which can have a large payload in the response. This may work as long as the clients can actually handle the large responses at a memory level, but skirts around the fact that processing which requires loading a new package before continuing will still increasingly stumble if package sizes become excessive. This is about helping to avoid this situation earlier if possible.
The text was updated successfully, but these errors were encountered:
What is the problem you want to solve?
If a daml package is very large, it can cause problems for clients that have to block processing to download and parse it. Ideally application logic should be split into independent, modular components, which can exist in separate packages.
What is the solution you would propose?
Have the daml compiler issue a warning when the resultant dar is excessively large. The message could link to documentation describing how to split packages up, and discussing the rationale for doing so.
The threshold size is TBD, but could perhaps be configurable.
Describe alternatives you've considered
Status quo
We have observed that over time packages can grow larger incrementally, and cause progressively more problems for tooling and clients.
Warning at the
UploadDarFile
stageThis could be done as well, but is later in the process. The daml build is the earliest stage at which we can determine the package size.
Additional context
There has been discussion of setting the
max-inbound-message-size
for GRPC to be a very high value in ledger clients we build, so that we don't get unexpected failures when issuing rpc's likeGetPackage
which can have a large payload in the response. This may work as long as the clients can actually handle the large responses at a memory level, but skirts around the fact that processing which requires loading a new package before continuing will still increasingly stumble if package sizes become excessive. This is about helping to avoid this situation earlier if possible.The text was updated successfully, but these errors were encountered: