New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Limit the size of aggregated WebXDC update #4825
Labels
Comments
iequidoo
added a commit
that referenced
this issue
Apr 23, 2024
iequidoo
added a commit
that referenced
this issue
Apr 24, 2024
Before, update sending might be delayed due to rate limits and later merged into large messages. This is undesirable for apps that want to send large files over WebXDC updates because the message with aggregated update may be too large for actual sending and hit the provider limit or require multiple attempts on a flaky SMTP connection. So, don't aggregate updates if the size of an aggregated update will exceed the limit of 100 KiB. This is a soft limit, so it may be exceeded if a single update is larger and it limits only the update JSON size, so the message with all envelopes still may be larger. Also don't send any updates together with the WebXDC instance to not complicate the code, the only downside is sending one message more when resending or forwarding WebXDC instances.
iequidoo
added a commit
that referenced
this issue
Apr 26, 2024
Before, update sending might be delayed due to rate limits and later merged into large messages. This is undesirable for apps that want to send large files over WebXDC updates because the message with aggregated update may be too large for actual sending and hit the provider limit or require multiple attempts on a flaky SMTP connection. So, don't aggregate updates if the size of an aggregated update will exceed the limit of 100 KiB. This is a soft limit, so it may be exceeded if a single update is larger and it limits only the update JSON size, so the message with all envelopes still may be larger. Also don't send any updates together with the WebXDC instance when resending it to not complicate the code, the only downside is sending one message more.
iequidoo
added a commit
that referenced
this issue
Apr 26, 2024
Before, update sending might be delayed due to rate limits and later merged into large messages. This is undesirable for apps that want to send large files over WebXDC updates because the message with aggregated update may be too large for actual sending and hit the provider limit or require multiple attempts on a flaky SMTP connection. So, don't aggregate updates if the size of an aggregated update will exceed the limit of 100 KiB. This is a soft limit, so it may be exceeded if a single update is larger and it limits only the update JSON size, so the message with all envelopes still may be larger. Also don't send any updates together with the WebXDC instance when resending it to not complicate the code, the only downside is sending one message more.
iequidoo
added a commit
that referenced
this issue
May 21, 2024
Before, update sending might be delayed due to rate limits and later merged into large messages. This is undesirable for apps that want to send large files over WebXDC updates because the message with aggregated update may be too large for actual sending and hit the provider limit or require multiple attempts on a flaky SMTP connection. So, don't aggregate updates if the size of an aggregated update will exceed the limit of 100 KiB. This is a soft limit, so it may be exceeded if a single update is larger and it limits only the update JSON size, so the message with all envelopes still may be larger. Also don't send any updates together with the WebXDC instance when resending it to not complicate the code, the only downside is sending one message more.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently update sending may be delayed due to rate limits and later merged into large messages. This is undesirable for apps that want to send large files over WebXDC updates, e.g. application updates sent by the store bot or large files imported via
importFiles
, because the message with aggregated update may be too large for actual sending and hit the provider limit or require multiple attempts on a flaky SMTP connection.Updates should not be aggregated to pending updates if the size of aggregated update will exceed some limit, e.g. 100 kB. Adding an option for configuring this limit and splitting updates that are themselves larger than this limit is out of scope of this issue.
The text was updated successfully, but these errors were encountered: