It seems this is indeed caused by the length of the payload, however blocking seems to be happening at Cloudflare level (which seems to be in front of TinyURL), which just returns 403 without further explanation.

Not sure how to debug _why_ Cloudflare doesn't like these longish URL params right now.

This issue doesn't seem to occur as regularly on Wikidata because they do not use tinyurl for shortening.

It seems like there is a possible fix in the UI to do something better than showing a blackbox; in addition to this it would be nice to fix the cause of this happening so regularly (perhaps by selecting and configuring a different URL shortener T362888 ?)

Moving to the product backlog; I believe this now requires some input from @Charlie_WMDE about what a more graceful failure method would look like

It's not a black box on chrome but a slightly more graceful error image:

This query doesn't fail because it's too long, but because Cloudflare likely thinks it contains a SQL injection. It works just fine if you remove concat from the query before trying to shorten the link.

Cloudflare's error message when manually calling TinyURL in a separate tab:

This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.

This patch (https://github.com/wbstack/queryservice-ui/pull/292) introduces the following:

1. Switching from GET to POST to mitigate any future length issues
2. Using Ajax instead of an <iframe> for improved error handling
3. Base64 encoding the query before shortening to avoid getting falsely flagged

Looks great, we talked about @dang going ahead and shipping this today but we realised that we'd not really talked about that as a team (taking and shipping your patch). We agreed to wait until Monday but wanted to remember to have a chat about maybe changing our working mode to agree we'd pick up tickets like this and drive them forwards while people are away.

I wonder if we also want to upstream this change?

Ticket to upstream this fix T381578