Closed mrakn closed 4 years ago
@Wajeed-msft can you assist?
@mrakn , Currently message size limit is 28 kb. Please raise a user voice for this so we can take up for feature request.
Unfortunately no, this is the limit currently. The team is exploring the possibility of increasing it in the future.
@clearab Is there another issue that is tracking this?
No, there isn't an Issue tracking this. The limitation is applied by the Teams backend services, and is universal in that infrastructure. We've made their product group aware that this is a common ask - if you'd like to add your voice to that you can reach out to them directly using one of the methods outlined here: https://aka.ms/teamsdevfeedback.
Just for the reference, here are all existing User Voice suggestions related to size limits in MS Teams if anyone would like to vote and add own insights:
Hi @clearab is there any change happen on the MAX size limit for message size.
@Sujit-Gaikwad - We will check it internally with engineering team and get back to you.
@mrakn ,@Sujit-Gaikwad - The feature for increasing the size limit is currently in dev state and there is no ETA to share.We will inform you once we get any update.
@mrakn - thanks for posting the UserVoice links. Since those sites have all been taken down, here is the link to the most relevant Feedback Portal item I could find:
Microsoft Teams - Remove the limit on the length of messages
Hi @Nivedipa-MSFT @v-chetsh , we have been seeing this issue regarding message size for a while too.. is there some way teams can lift this limitation? Any update from the engineering team?
@devtfq - We are checking it with engineering team and let you know the updates.
Thank you @v-chetsh
Hi @v-chetsh @Nivedipa-MSFT , can we please change the status to 'Open' as the problem still persists? I can see the same issue raised in multiple forums as well, but sadly no fix has been provided by MSFT so far.
@devtfq - We are checking it internally with engineering team and inform you accordingly. I am not seeing a option to re-open it. @mrakn - Could you please help me to reopen it.
@devtfq - The feature for increasing the size limit is currently in dev state and there is no ETA to share.
Hi @v-chetsh @Wajeed-msft ,is the size limit lifted ?
Could you kindly check with the development team? Just doubtful as I am able to see a significant improvement in the card size.. I am able to send data which I was not able to send about months before.Its coming out fine. Can we please check once?
@v-chetsh could you kindly check with the development team once?
@devtfq - We are checking with the engineering team. We will get back to you soon.
@Nivedipa-MSFT thank you so much. Eagerly waiting for the response
Morning, @devtfq / @Nivedipa-MSFT. I can confirm that, as of this morning, I am still getting the following error if the card size passes some limit. Not sure what that limit is, but, if I attach too large of an object to the Value property of an action button and add that to a Hero Card, I get the following error:
Operation returned an invalid status code 'RequestEntityTooLarge'
I understand @jcbartle , but i feel some improvement came across the size limit. For my use case., along with the remaining card payload, I was not able to send a particular choice set whose elements totally consist of 1700 characters, but now I am able to send the same payload.. also I'm able to send the choice set with total element size of about 5200 characters too..along with the remaining data, thus indicating an improvement
Still there has to be a limit of course, but just that for my use case I am seeing a considerable improvement.. and thus wanted to confirm it with the engineering team .
@Nivedipa-MSFT could you please tell us if there are any updates from the team so far regarding the size limit?
@Nivedipa-MSFT do we have an update from the engineering team?
@v-chetsh and @Nivedipa-MSFT, thank you so much for the updates. Unfortunately I cannot reopen this issue since it has been closed by repository collaborator - @clearab.
@mrakn - Do you have any further query? If yes could you please create another issue for the same.
Any update on this? Is there a way we can compress and decompression happens at MSFT side
Any update on this? Seems like it has not been updated for a couple of months.
@jacksonngoo - We will check the status from engineering team and update you soon.
Any update on this?
@ahmedmahmoudR - We are checking the status with the engineering team. We will let you know once we have any updates on it.
Hello @ahmedmahmoudR - Sorry for delay in response. Just wanted to inform you that we are checking the status of this ask with engineering team and let you know once we get any input from them.
@ChetanSharma-msft any update on this adaptive card message size increase?
@SURYASARAVANAN - We are checking this with engineering team, we will let you know once we get any update from them.
@Nivedipa-MSFT @ChetanSharma-msft it's been 2 years since users reported this concern and feature request and please let us know the exact update as it is affecting a lot of customers and it's an important feature which lags here.
@Nivedipa-MSFT any updates? this update is important to us. Once this is resolved, we will be able to improve communication within organizations.
@Gorkes, @SUNNUWORKS, @mrakn - We got an update from engineering team saying that message size limit has increased up to 40 KB.
Below document has updated with message size limit 40 KB.
Ref Document: Format your bot messages
@Nivedipa-MSFT Want to understand, is this hard limit for any particular reason?
We have a requirement and we believe it will go double the limit size (80kb). Want to understand if this hard limit is for any particular reason or if this can further be increased upon request?
@raguravindran - We will check this with engineering team and update you soon.
@Nivedipa-MSFT Today I tried again but got the same error: "error": "The payload is too large. Make sure the size is less than 28KB." Is it possible to check with the development team about the 40kb limit? it's too low.
@raguravindran, @Gorkes - The message size limit is from chat service and there is no way to increase as this limit is also applied in other scenarios.
I have tested the limits using byte counted payload and any messages over ~14kB are not allowed for me (not using a dedicated bot). This is obviously a small limit and the major part of the JSON payload is a somewhat redundant "encapsulation" in the form of table or other components in the JSON.
Removing even simple styling parts such as "weight": "Bolder" sometimes yielded observable savings (e.g. 40-50 bytes on 100 records). Without a separate limitting algorithm inside the payload producer it doesn't even make sense to send dynamic content messages, because most of the time they just won't arrive.
I absolutely agree with the OP, especially on the flawed data structure. Additionally, why does the backend send back "X-Proxy-BackendServerStatus": "200", in the headers when the content says "... delivery failed with error: ... 413"? Python for example won't pick it up using response.status_code
It makes it needlessly difficult to handle these payload limit exceptions.
Is there a way for me to test a card's size before sending to determine if it's too large?
I have chatbot powered by .NET Bot Framework V4 and the primary communication channel that is used to communicate with the bot is Microsoft Teams.
I have a use case where based on user's input I call an APIs and based on the responses I dynamically build the adaptive card that is then sent to the user. There are however few instances, where trying to send the AC to the user results in error 413 - RequestEntityTooLarge:
{ "error": { "code": "MessageSizeTooBig", "message": "Message size too large." } }
I am aware, that this happens, because the maximum allowed length of MS Teams' message is only 28 KB based on following doc. This limitation is very inconvenient for scenarios where I try to send over adaptive card that is slightly more complex. I could understand the limit for plain text, but I think it is too small for cards, since majority of actual message content is JSON / metadata.
Is there any way how this limit can be increased or overcome in any way, something like instructing the channel to not apply the limits because the message is attachment / adaptive card? I have seen some suggestions about splitting the card into multiple parts, but this is not an option for me.