Use `skipkeys` when serializing payload

[lbolla]

See comment https://github.com/getsentry/raven-python/issues/1155#issuecomment-473423879

When serializing error data (traceback, local vars, etc.) to be sent to the backend, json.dumps is used, in raven.utils.json. json.dumps can fail, e.g. when local data has the form:

{ (): "foo" }

which cannot be serialized to json (because of the tuple key). By using json.dumps(skipkeys=True) these kind of keys will be ignored.

[ohimors]

@lbolla When is this going to be done? Isn't this a one-line fix? Does this product even work?

File "/usr/local/lib/python3.6/site-packages/raven/utils/json.py", line 63, in dumps\n    return json.dumps(value, cls=BetterJSONEncoder, **kwargs)\n  File "/usr/local/lib/python3.6/json/__init__.py", line 238, in dumps\n    **kw).encode(obj)\nTypeError: __init__() got an unexpected keyword argument \'encoding\'\n'

[lbolla]

@ohimors I've already submitted a PR ages ago: https://github.com/getsentry/raven-python/pull/1350 But I've since moved to use the new "Sentry SDK", given that "raven-python" is deprecated. I don't know if the maintainers are actively working on Raven anymore.

[untitaker]

I'll look into this on Monday. We still want to fix bugs in Raven.

[untitaker]

• The encoding error only happens when another exception is already being thrown on Python 2. So the real bug here is that the exception for e.g. ()-keys is clouded by this error, but it's not inherently broken under Python 2.
• We cannot use skip_keys. It's way too broad in how it operates and discarding is not the way to go.
• We already stringify dictionary keys in raven.serializers.base.DictSerializer. I wonder why this is not applied in this case.