Added new section in README.md to clarify how to do local testing of …

[comolongo]

Added new section in README.md to clarify how to do local testing of event functions. Fixes the questions raised in issue #37.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[stew-r]

This is a great contribution -- thank you!

@ace-n @grant think we can have this exist as a separate testing doc?

@comolongo have you tested whether this actually works with the Pub/Sub emulator? I think we have an issue right now where Pub/Sub messages are transformed in our infrastructure before reaching the container with your function. This means that the framework expects a slightly different message format.

To be clear: this is a bug that we need to fix. We just haven't gotten around to it yet.

[grant]

@stew-r I recommend that we have a docs/ folder in this repo for advanced documentation.

I can create that:
#42
Advanced guides should talk about things like using the emulator, multiple functions, etc.

As we gain more options for using the Functions Framework, this folder can help support docs.

[comolongo]

Hey @stew-r , yes I have tested this with the PubSub emulator, and it does have the issues you're talking about. I was able to overcome it, by hacking the wrapEventFunction() in invoker.ts and filed ticket #41 to address that specifically.

On the topic of the PubSub emulator incorrectly transforming the messages, at least from my tests, it seems like the emulator is pushing notifications using the same format as on prod - i.e. it seems like the actual body of their push notification is correct. The issue may be that the emulator needs to include the right header flags for invoker::isBinaryCloudEvent() to return true. Currently it is returning false, and causing wrapEventFunction() to go down the wrong else clause.

[stew-r]

@grant I like the structure -- thanks!

@comolongo so I think the issue is somewhat different (though your solution addresses it too). In short:

• Pub/Sub sends a message
• In Google Cloud Functions, we have a piece of infrastructure that receives the message and applies some transformation before passing it on to the user's container
• The user's container thus doesn't see a Pub/Sub message but a transformed Pub/Sub message

When running locally (or a different container-based environment), we don't perform this transformation. So your function sees something different based on whether it is running in Google Cloud Functions vs. elsewhere.

As you've discovered, this is solvable. Thanks for submitting a fix, I'll make sure to pass it along to the eng team.

[grant]

@comolongo Could you change this PR to add this content into the docs folder?

[ghost]

Might be handy for typescript users if it is stated that the entry file is dictated by your "main": "./lib/index.js", property in package.json?

It just seemed a little odd to me that I could not add an argument to the command, most testing CLIs follow that flow.

[grant]

@comolongo Could you move markdown content into the docs/ folder?

I'm trying to resolve PRs within 30 days. If there's no reply, we should add the guides outside of this PR.

[betacar]

May I also suggest to add the CE-* headers, maybe with a truthy value, to the docs so the lib can know that the request is for a Cloud Event?

curl -d "@mockPubsub.json" -X POST -H "Ce-Type: true" -H "Ce-Specversion: true" -H "Ce-Source: true" -H "Ce-Id: true" http://localhost:8080

This would help with issues like #41, and also set the values correctly to the data and context arguments.

[grant]

Hey @comolongo,
Can you move the change here to the docs/ folder? I'll merge this right after.

[grant]

Closed due to inactivity.