Injecting a serialization strategy

[rtek]

The serialization of the objects in the stack trace has been problematic since V1 due to the coupling with the Utilities class. The issue is that we can not (and/or should not) implement an interface to allow for serialization in rollbar. For classes we do not control, its not possible, and for classes we do control, modifying the class solely for rollbar serialization introduces multiple code smells (e.g. separation of concerns, encapsulation, coupling to rollbar, etc). See https://github.com/rollbar/rollbar-php/blob/master/src/SerializerInterface.php.

I needed to see complex objects from third party libraries (such as \GuzzleHttp\Exception\RequestException) in the stack traces, like this:

I monkey patched around this in V2 by replacing the utilities property on the Payload object. In V3, autoloading a shim of UtilitiesTrait made it compat with V2.

If there is interest in this I can contribute a concept.

[danielmorell]

I whole heartedly agree with your assessment on implementing the SerializerInterface. Definitely not an expectation that should be placed on you or third party packages. The intent of the interface is for internal use within the Rollbar package.

I was not around back in the v1 days. Could you provide a little more information about the customizations you are making? It would be nice to get object serialization to work for you out of the box without the need for monkey patching.

[rtek]

Here is a stripped down POC:

https://github.com/rtek/rollbar-php-serializer

• Patch contains the mechanism in which I override the Utilitites in Payload
  • Autoload the shim to replace UtilitiesTrait
  • Extend RollbarLogger to replace the Utilities object on the Payload to hook in here: https://github.com/rollbar/rollbar-php/blob/master/src/Payload/Payload.php#L51
• Serializer contains an opinionated serialization implementation for the Rollbar\Payload classes (PayloadSerailizer), primitive PHP types (DefaultSerializer), and a simple PSR7 serializer (Psr7Serializer).

The demo in test yields pretty PSR7 arguments like this in the trace (see tests/_files/output/demo.json):

{
    "filename": "rtek/rollbar-php-serializer/tests/DemoTest.php",
    "lineno": 54,
    "method": "Rtek/Rollbar/Tests/DemoTest::Rtek/Rollbar/Tests/{closure}",
    "args": [
        {
            "__": "GuzzleHttp/Psr7/Response#80",
            "status": "HTTP\/1.1 400 Bad Request",
            "headers": {
                "Foo": "bar,baz"
            },
            "body": "foobarbaz"
        }
    ]
}

[rtek]

To clarify - I wouldn't propose that rollbar implement any serialization besides the type, and other anonymous things, such as the object identifier. If serialization can be customized, then rollbar can jettison the scrubbing phase and make it the responsibility of the user.

[danielmorell]

Thank you for the all the extra information and explanation! It will take me a just bit to go through your example and grok the whole thing.