Ok, I don't mind naming that much.

Maybe, but this situation should simply never occur and if this check passes, it means that something went really, really wrong.

Moving suffices.
This code

// Example program
#include <iostream>
#include <string>

int main()
{
  std::string s1 = "aaa";
  std::string s2 = std::move(s1);
  std::cout << s1.size() << std::endl;
  std::cout << s2.size() << std::endl;
}

Gives output:

0
3

I think we should check for the size and set the limit at some point. At most, it should be just chunkLimit - extraBytesNeeded(aka padding). This is because, if the internal buffer grows beyond the chunk limit, we'll not be able to send it in the end - in the end, we check if the internal buffer is empty and if it's not, we're sending one more message containing its contents.

In case we don't set an upper limit for this, there are 2 problems:

• we'll have to implement even more complicated logic for sending more than one message in the end
• we won't control the growth of the internal buffer, and what comes next, we'll not be able to know how much data we'll have to allocate for the internal buffer.

I'm going to change the limit from the chunkLimit/2 to chunkLimit - padding

One more thing: This is a sanity check, in the real world this should never be exceeded. Let's assume we have 10KB of the additional data (which is way too much for a couple of ids anyway). Then, with every message the internal buffer's going to grow by 10KB, which means it's going to reach this new limit after 399 messages:

4MB = 4 000 KB
limit = 4 000KB - 10KB = 3990KB
3990 / 10 = 399

That means, we'd need a blob that would take 399 * 4MB = 1596MB = 1,5GB+
Since 10KB for ids is way too much, let's go with 1KB as well:

limit = 4 000KB - 1KB = 3999KB
3999 / 1 = 3999
3999 * 4MB = 15996MB = 15GB

I don't think we're going to end up having a simple blob of 16GB, even 1.5GB. Please, keep in mind that we're talking about the blobs that are supposed to be fetched through the backup service. So that doesn't apply to pics/vids, just the database records since media's going to be added as attachment holders and fetched directly from the blob to the client, right (hope I didn't miss anything)?

Ok, I'm going to change this name to PrepareDataChunkWithPadding

My motivation was to avoid even more complex logic. This code is already complicated and may be hard to read. We can send the data every time it goes up to the limit but it's going to make the machine state harder to understand and maintain. I understand your point, but please note, that it wasn't "pointless" - I just didn't want to sacrifice readability for an edge case that will probably never happen.

But I understand what you're saying and I basically agree. I still think the entire idea here is pretty bad, but I will update this logic anyway.

In which diff this code is introduced? I can't see it in any of this diff's dependencies.

We can make this condition less restrictive

In which diff this code is introduced? I can't see it in any of this diff's dependencies.

D4555

We can make this condition less restrictive

Right, I will update this code in the diff I mentioned, thanks!