Add input data to processed messages

[SpartakusMd]

Fixes #17

• Uses symfony/serializer to normalize the message from the envelope.
• Stores the data into the input field
• Didn't work on tests yet, until it's confirmed the approach is good

[kbond]

Thanks for the PR @SpartakusMd! I'm quite swamped at the moment so I'll give it a proper review (and start working on the other issues) when I have a chance.

Curious about what you said in the issue:

It gives the possibility to process the data later

Using symfony/serializer makes this difficult to do, right? If this is a valid use case, I wonder if we shouldn't use messenger's serializer. Then, when the user wants to re-run the message, we should just be able to unserialize and send to the bus. To keep the info available in the UI, we'd unserialize the data (using the messenger serializer), then normalize (using symfony/serializer). I hope that makes sense...?

[Chris53897]

Did you test enums? Enum-Support could be added later (If not supported yet)

[aborza]

Added enum support

[Chris53897]

Thanks for the PR. Look already promising.
And of course a rerun option would be great.

[aborza]

The input appearance on details page:

[aborza]

To include the following fix symfony/symfony#52852 for symfony serializer

[SpartakusMd]

@kbond what do you think about the implementation? We're using the fork now in production and improves a lot the debugging life.

[kbond]

Looks good, I'm going to be adding this bundle to an ap so I'll be able to test this out locally soon.

[SpartakusMd]

@kbond I found an issue related to emails. If the email is sent via Messenger, it will also be captured and save to the database. The problem comes when the message contains attachments, they will also be serialized and saved to the database. I propose to clone the message before serializing and remove attachments from it. What do you think?

[SpartakusMd]

In the end, I have added a new stamp DisableInputStoreStamp to disable saving the input.

[SpartakusMd]

Hello @kbond, did you have time to check the changes?

[kbond]

Hey @SpartakusMd!

Sorry for the delay - I haven't forgotten about this!

I'm pretty sure the next pre-release is going to require a migration because of #105 so feels like a good time to add this feature.

I think I'm going to add a global config to disable/enable the result storage by default, then add EnableResultStoreStamp/DisableResultStoreStamp (to use depending on your global config). Thinking we should do the same with this feature also (global config + EnableInputStoreStamp/DisableInputStoreStamp).

Also, for the Email attachment issue, could we detect when a field is binary (the case for attachments) and just replace with (binary)?

Thoughts?

[SpartakusMd]

Hello @kbond, sounds good the config and stamps.

Regarding email attachment, I didn't find a way to eliminate binary fields from being saved in the DB.

[bendavies]

awesome feature!

[SpartakusMd]

@kbond could we move forward with this PR? I would like to add some extra functionality on top of it and avoid piling all the changes in a single PR, which would make the review harder.