A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://github.com/umbraco/Umbraco.Deploy.Issues/issues/144 below:

Base64 image in a RTE stalls the deployment · Issue #144 · umbraco/Umbraco.Deploy.Issues · GitHub

When there is a base64 image inside an RTE it completely stalls the Deployment until the deploy timeout limit is reached.

Reproduction Specifics

Umbraco: v9.5.4 and v10.3.2
Deploy: v9.5.2 and v10.1.2

Steps to reproduce
  1. Create a document type with an RTE editor and allow it as root.
  2. Add the base64 image to the RTE from the txt file I've attached.
    base64image.txt

  1. Publish the node. (This will probably end with an exception since the CMS doesn't like these base64 images either)
    However, refresh the page and you'll have a node to transfer to the next env.
  2. Try transferring the node and it should stall/hang on Create manifest on source

This is what the CPU usage looks like during the deployment of this one node.

Bug summary

Basically, base64 images are the devil 🙈

In the past, we have seen major issues with base64 images causing CPU spikes in the CMS during preview or publishing. Often completely killing the application. Processing/serializing these base64 strings seems to be very resource intensive.

Old CMS issues for reference:

Not sure if this needs to be fixed in the CMS or Deploy, though it seems like more of a CMS issue at first glance.

The main reason for creating this issue on the Deploy tracker:
If it can't be fixed in Deploy I would like improved logging so it's faster to debug it. Right now, even with Debug logging enabled, there is no information on which node is being processed. If the node id was logged out it would be easier to know at what point it stalls/fails. Speially when it's a large deployment with hundreds of nodes.

When I was debugging with the source code in Visual Studio I was able to log out the content id here. That enabled me to figure out the issue pretty quickly but getting to that spot was a huge pain.

Expected result

It transfers the node blisteringly fast

Actual result

It hangs until the deploy timeout is reached.


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4