Change 450210 had a related patch set uploaded (by Santhosh; owner: Santhosh):
[mediawiki/extensions/ContentTranslation@master] CX2: Handle the MT failures gracefully

https://gerrit.wikimedia.org/r/450210

Change 450210 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] CX2: Handle the MT failures gracefully

https://gerrit.wikimedia.org/r/450210

After this patch, users are no longer stuck with three loading dots after MT translation fails. When the failure happens, we show "Add translation" placeholder again.

In some cases, no matter how many times we try, we're just gonna get the same failure again. One such case is when translating really big section, like some tables. That scenario leads to 500 internal server error because request payload is too large.

Such errors are bound to happen no matter how many times we try. The question is: should we try being smart and predict some scenarios where user simply cannot translate the section? How would we communicate that in the UI?

@santhosh, should we deal with payload limit errors more gracefully regardless of translate-retry cycles I speak above? Should we strip the payload not to get this error?

{
    message: "request entity too large",
    expected: 107790,
    length: 107790,
    limit: 102400,
    type: "entity.too.large"
}

@Petar.petkovic If there are 5 continuous save failures, we show a red error banner at the top of the translation view. All schedulers will be stopped. Ref the following code snippet.

			if ( this.failCounter > 5 ) {
				// If there are more than a few errors, stop autosave at timer triggers.
				// Show a bigger error message at this point.
				this.translationView.showMessage( 'error', mw.msg( 'cx-save-draft-error' ) );
				// This will allow any change to trigger save again
				this.failCounter = 0;
				mw.log.error( '[CX] Saving failed repeatedly. Stopping retries.' );
			} else {
				// Delay in seconds, failCounter is [1,5]
				delay = 60 * this.failCounter;
				// Schedule retry.
				setTimeout( this.processSaveQueue.bind( this, true ), delay * 1000 );
				mw.log( '[CX] Retry scheduled in ' + delay / 60 + ' minutes.' );
			}

I am interested in knowing how you get this payload error. Any steps to reproduce? Are we queuing up too much data and sending in request by any chance?

In T200686#4513868, @santhosh wrote:

I am interested in knowing how you get this payload error. Any steps to reproduce? Are we queuing up too much data and sending in request by any chance?

Created T202283: CX2: Big sections are untranslatable, where one example is provided. Errors occur when you try to "Add translation" and MT fails because of big payload. I don't think we queue these request, so that isn't the problem.