Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[gps] Consuming message from external publisher in non-standard format #1117

Closed
maciejzgadzaj opened this issue Dec 2, 2020 · 12 comments
Closed

Comments

@maciejzgadzaj
Copy link

I have a Symfony app with messenger using enqueue/gps to send/consume Pub/Sub messages. Everything works fine as long as messages are published and consumed by my app - they are in the format expected by GpsMessage, with body, properties and headers at the top level.

But now I need to also consume messages sent by an external publisher, which do not adhere to this format - talking specifically about messages sent by Gmail API Push Notifications, which look like this: {"emailAddress": "[email protected]", "historyId": "9876543210"} (https://developers.google.com/gmail/api/guides/push#receiving_notifications) - no body, no properties and no headers.

Trying to consume a message like this, GpsMessage gives me an error Notice: Undefined index: body, and fails.

Would appreciate any advice how can I make this work?

@makasim
Copy link
Member

makasim commented Dec 3, 2020

I guess, the solution would be to make an attempt to parse message body and see weather it has properties, headers, body in it.

If not, we can fallback and treat the body as body with empty properties and headers.

@makasim
Copy link
Member

makasim commented Dec 3, 2020

@maciejzgadzaj
Copy link
Author

Ah, ok, thank you. Was hoping that it might be somehow doable with the current version.

I'll look into necessary modifications.

@maciejzgadzaj
Copy link
Author

Ok, here's a first draft. I'm testing it now with my app, and setting up repo env to run tests etc, but so far it seems to work ok. Thoughts?

@stale
Copy link

stale bot commented Jan 3, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Jan 3, 2021
@maciejzgadzaj
Copy link
Author

Hi @makasim - is there anything preventing you from merging this?

@stale stale bot removed the wontfix label Jan 4, 2021
@makasim
Copy link
Member

makasim commented Jan 4, 2021

It looks good. Last thing is CI complaing about code style https://travis-ci.org/github/php-enqueue/enqueue-dev/jobs/748125221

@maciejzgadzaj
Copy link
Author

Yes, I've seen it, and I've chosen to ignore it - as it complains about the section which I haven't changed, and also, running the tests locally doesn't raise this issue at all. I guess we shouldn't really care about it here then?

@makasim
Copy link
Member

makasim commented Jan 4, 2021

I understand that the CS issue is irrelevant to your change. Some times it happens.

Could you please make CI happy ? I am okay to merge PR once CI green

@stale
Copy link

stale bot commented Mar 19, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Mar 19, 2021
@maciejzgadzaj
Copy link
Author

Sorry, got distracted with work (can you imagine!), and completely forgotten about this (thanks stale bot for the reminder!) Just rebased and repushed, all is nice and green now, into your hands then @makasim !

@stale stale bot removed the wontfix label Mar 23, 2021
@makasim
Copy link
Member

makasim commented Mar 24, 2021

Thanks, merged.

@makasim makasim closed this as completed Mar 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants