Jacob D

Upload speed too fast causing "an error occurred" is fully reproducible for me, and has a rough break point around 5MiB/s or 40Mbit/s. Speeds above this consistently fail, speeds below consistently succeed.

Environment

• Windows 10 pro (19044.1826)

• Minecraft Bedrock 1.19.11 (7/26/22)

• World size: 193MB, no mods, survival

• Realms Service:
  pocket.realms.minecraft.net
    ->{{ archive-pocket-production-us-east-1.realms.minecraft.net}}
    -> realms-production-archive.eastus2.cloudapp.azure.com
    ->{{ 52.242.86.73}}

Procedure

Bandwidth limit set via PFSense router.

1. Create a new traffic limiter (Firewall->Traffic Shaper -> Limiters) menu, new, set to XX MBit/S, name = mctest

2. Create a new firewall rule (Firewall -> Rules -> Home) destination "single host" host

3. Assign the limiter via Advanced -> In/Out Pipe, in=mctest

Results 

Note that the actual upload speed is only approximately limited by the router, so these number should be treated as an average rather than a hard max. Other ways of limiting bandwidth (best is client side) may succeed with faster speeds.

Discussion

Interestingly, these numbers are an order of magnitude smaller than the rate limit claimed by Azure Blob Storage - so there may be other factors at play (is there API Server buffering of incoming data, waiting a set time before opening the Azure Blob Storage connection?).

Regardless, it is clear that speed is the factor that causes the latest "An error has occurred" failure with "the new network stack"

This explains a number of the otherwise unrelated symptoms described in these comments:

• small worlds work - if the world is too small to sustain bandwidth that triggers throttling, it will work as expected.

• works from mobile - mobile devices tend to be limited to lower bandwidth, high latency, and many dropped packets

• works when tethered to mobile hot spot - again, slowing the bandwidth (rather than having to do with firewall/ipv6)

• works sometimes - when speeds are close to the threshold, intermittent success is possible depending on backend load

Do hope that the team ( @CornerHard ) can investigate this ASAP - check application and infra logs for 5xx errors in blob storage would be a good start.

I personally have a workaround but most players will not be able to sniff the network for their realms API server IP and add targeted bandwidth throttling 🙂

So, after waiting patiently for 1.19(.11) to come out, and hoping to believe that it was actually a fixable client side issue, I was disappointed to find that it still doesn't work 😞 I am 100% sure it's not on my network side, I have FiOS 1GBE, hardwire ethernet to the ONT, consistently speed tests 890+mbit up and 950+ mbit down. 

I did stumble on a blog post from last year (about the time I started having issues) explaining that Realms was migrated from AWS to Azure (https://developer.microsoft.com/en-us/games/blog/how-minecraft-realms-moved-compute-storage-from-aws-to-azure/) and found it interesting to see that they load the old world from AWS/S3 but write changes (probably also uploads) to Azure Blob Storage. I'm pretty sure that my account is somehow tied to this migration mechanism, since the DNS lookup the game makes before trying to upload is realms-production-{*}archive{*}.eastus2.cloudapp.azure.com (an alias for {*}archive{*}-pocket-production-us-east-1.realms.minecraft.net) emphasis on archive added – I originally signed up for realms on PE, years ago, to migrate my then "Classic" world from an ancient iPad to PC. Whatever this server is, is behaving badly with TCP/IP - all sorts of out of order acks, looks like it's out of memory or swap space or something.

I am tempted to cancel my subscription (from Apple) and reactivate it through the Microsoft store, to see if I get assigned a different server... 

I canceled my Apple-based subscription and signed up through the Minecraft UI (Microsoft  Subscription), but the game is still using archive-pocket-production-us-east-1.realms.microsoft.net 😞 so either (a) there is some flag set in my xbox live account, or (b) everyone is using the archive-pocket-production server(s). Guess I'll cancel the new subscription as well, until there is better news here... 

Ahha! After some more digging, I now think that the "archive" was a red herring - there is some (unofficial) API documentation on the realms REST API that includes sample URLs with this pattern; the "archive" has to do with the game file management servers, which store save files while you're not actively connected and playing (see https://developer.microsoft.com/en-us/games/blog/migrating-minecraft-realms-from-aws-to-azure/). Seeing that REST API and reading about migrating from S3 to blob storage got me thinking - Azure Blob has a rate limit of 60Mb/s per blob object (see https://docs.microsoft.com/en-us/azure/storage/blobs/scalability-targets ), with a note on their docs that says:

When your application reaches the limit of what a partition can handle for your workload, Azure Storage begins to return error code 503 (Server Busy) or error code 500 (Operation Timeout) responses. If 503 errors are occurring, consider modifying your application to use an exponential backoff policy for retries. The exponential backoff allows the load on the partition to decrease, and to ease out spikes in traffic to that partition.

Going from that, and assuming that the Realms servers were never enhanced to support application-side exponential retry (because the S3 SDK does it for you) - I added a rate-limiter to the 52.242.86.73 ip address (my archive server) of 25MB/s in my router and BAM!  It worked! 

I will continue to test, but I do believe that the cause of at least some of these errors on the new network stack is internet that is *too* fast, saturating the Azure Blob, causing the Realms API server to freak out and the upload to fail.

It would be great if the Realms team can investigate this 😉 

Also on the Switch version.

I have been able to confirm this bug. See my video posted on bug MCPE-54664.

I can confirm that this bug exists on the Bedrock Switch Edition. Just uploaded a video in creative showing this problem.