Config SENTRY_MAX_MESSAGE_LENGTH does not work

[nbhuy89]

Hi,
I config SENTRY_MAX_MESSAGE_LENGTH to another number, but the message always be truncated at 1000 characters, how can i make it work?
I'm using sentry server version Sentry 9.1.1
Thanks,

[untitaker]

9.1.1 should have a limit of 8000 chars. Which message attribute do you mean? Could you provide a screenshot?

[nbhuy89]

Sorry, I rechecked, I see it truncate at 8000 chars like you said, Is there any way to increase this limit number?

[caseyduquettesc]

I found in 9.1 that SENTRY_MAX_MESSAGE_LENGTH was not working because the Rust processor (new) had a hardcoded message field size. Since 9.1's release, we've been running with this patch that disables the Rust processor trimming, which appears to be optional, with no problems. We increased max message length from 8KB to 256KB.

--- sentry/src/sentry-dev/src/sentry/event_manager_9.1.py	2019-04-25 10:06:31.000000000 -0700
+++ sentry/src/sentry-dev/src/sentry/event_manager_new.py	2019-04-25 10:06:48.000000000 -0700
@@ -444,7 +444,7 @@
             valid_platforms=list(VALID_PLATFORMS),
             max_secs_in_future=MAX_SECS_IN_FUTURE,
             max_secs_in_past=MAX_SECS_IN_PAST,
-            enable_trimming=True,
+            enable_trimming=False,
             is_renormalize=self._is_renormalize
         )

And in our Dockerfile,

patch /usr/local/lib/python2.7/site-packages/sentry/event_manager.py /etc/sentry/patchfiles/event_manager.patch

[BYK]

@untitaker do you know whether this was intentional or not?

[untitaker]

We didn't think that people would care about this setting. I would be cool with a single setting that just turns of trimming altogether (like in @caseyduquettesc's patch) assuming that's fine-grained enough for most people who want this. Just make sure it's false by default :)

[troyvo]

@caseyduquettesc , just tested. It works like a charm. you save my time. Thanks

[jan-auer]

It might be worth noting here that we're planning to move all of that code into a new, separate service. As part of this, many of these settings might no longer be configurable going forward (such as trimming, for instance).

Might I ask what the use case is for such large messages? With event attachments (basically file uploads that show up on the issue details screen), we might have a suitable alternative in Sentry 10.

[caseyduquettesc]

@jan-auer
One of our projects in our on-prem setup is for android crashes. But the crashes don't come directly to Sentry; they go through a proxy for automatic triaging, symbolication, and doing Jira integrations before it gets forwarded to Sentry using the standard java client to send. These crashes don't use the exception interface, and dump all the information into the message field plus tags. This data can be large (up to 0.5MB) if it includes thread dumps. I understand this is arguably improper use of the tool, but that process was before my time. Ideally it would use extra data and exception fields properly, but for now, this is what I'm stuck with.

I completely understand that your roadmap may not necessarily support my use case and we've accepted that we have sort of gone off book here. I appreciate that you asked though and hope you just continue to keep doing what's best for the product, it's great.

A warning for anyone else disabling trimming and inserting large messages - it will absolutely kill your snuba/clickhouse service with searching large messages. I had to just disable message searching entirely for this one project until I can figure out either how to reduce the message size just in clickhouse or migrating message searching to something like elastic search.

[BYK]

Closing this issue due to staleness. Feel free to comment here if you think we should still work on this.

Regarding @jan-auer's last message, this new service, Relay, is now part of Sentry deploys. You can find more information over at the docs: https://docs.sentry.io/product/relay/