All arrays are currently being truncated to "Array of length N":
... and yet dictionaries are fully expanded. We are getting feedback from users with error data containing small arrays (e.g. 1-5 items) that are frustrated that they cannot see inside.
Yes, frustrating!
I'm closing this out as we expand arrays in PHP.
This issue still exists. Will it be fixed?
Just ton confirm, where are these arrays not getting expanded? (which section of the event)
Additional Data. For example, we receive JSON webhooks from 3rd parties and send events to sentry in case of failure. Attached an example of how one of these JSONs look in Sentry:

We should anyway limit the depth or let it be configurable, to avoid sending data too "deep".
I'm trying to recall why we went this direction in the first place. I think there were certain things where we didn't want the full data repr, but honestly dont recall where.
In my case, this additional data are required to make possible fix my issue, once that the problem is inside of this truncated array.
According to support this feature is intended to help keep error messages within the 100kb payload limit.
Maybe it would be possible to only flatten when the limit is hit, or make it opt-out? Those who are migrating from another solution (like us) are probably already having their error messages somewhat in check.
In the 1.8.1 release that just got out, we added setters for the serializers. You can replace them with the logic you prefer.
Hi @Jean85 can you give details about this method?
In my case the data truncated from $_SESSION are required to reproduce the error. To workarround the depth limit, I currently send a json encoded copy of $_SESSION (with pretty print) in extra param.
I'm referencing this piece of code: https://github.com/getsentry/sentry-php/blob/e1001f80d07f08cbf8d2648cb707ea43bf3e5794/lib/Raven/Client.php#L1457-L1471
Those 2 serializers are the classes responsible for the compression of those arrays. You can extend them and change the behavior for the desired stuff. But using the extra field like that is a feasible solution too!
Thanks @Jean85
Unfortunately setting the serializer was not useful in my case because the depth is set in Client::sanitize and wanted to set a greater depth for user data only.
I end up by ovewritting sanitize method to do the job. Here is an example in case it can help anyone:
class MyRavenClient extends \Raven_Client
{
/**
* @param array $data
*/
public function sanitize(&$data)
{
// Serializes the session items as a json string
foreach ($data['user']['data'] as $k => $v) {
if (is_array($v)) {
foreach ($v as $kk => $vv) {
$data['user']['data'][$k][$kk] = json_encode($vv, JSON_PRETTY_PRINT, 3);
}
}
}
// use parent sanitizer
parent::sanitize($data);
}
}
Be aware that serializer will limit the size of a string, and in this case it might be useful to provide an other serializer that has a greater limit on string size.
Also having this:

This relates to issues created via overriden Monolog's RavenHandler in Yii2 app (don't ask....).
I'll probably normalize trace to flat array, but still, this is frustrating.
Any movement on this? It would be great if serialization depth was configurable for each of the types of data this client attaches to Sentry events (user, extra, tags...).
Did you check out the new 2.0 release? The serializer has that option and it's completely replaceable if you want.
Also, for 1.x there's #632 which just needs to be released.
@Jean85 that's great news, thank you. Will definitely be trying that out.
This should be resolved in both 1.x and 2.x (but please use 2.x where possible).
Or well, the "culprit" is now configurable so if you run into this often it's possible to modify the settings for this behaviour.
1.x: #632
2.x: https://github.com/getsentry/sentry-php/issues/378#issuecomment-533318398
Most helpful comment
Thanks @Jean85
Unfortunately setting the serializer was not useful in my case because the depth is set in
Client::sanitizeand wanted to set a greater depth for user data only.I end up by ovewritting sanitize method to do the job. Here is an example in case it can help anyone:
Be aware that serializer will limit the size of a string, and in this case it might be useful to provide an other serializer that has a greater limit on string size.