Fix up empty namespaces JSON unmarshalling error

pmundt commented 4 years ago

At present, if the namespaces endpoint returns 0 bytes, there is still an attempt to unmarshal it, resulting in an unexpected end of JSON input error being passed down.

Signed-off-by: Paul Mundt paul.mundt@adaptant.io

Description

Motivation and Context

[ ] I have raised an issue to propose this change (required)
[ ] My issue has received approval from the maintainers or lead with the design/approved label

How Has This Been Tested?

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I've read the CONTRIBUTION guide
[x] I have signed-off my commits with git commit -s
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

alexellis commented 4 years ago

Hi thank you for your interest.

How Has This Been Tested?

Please give before and after and versions being used so we can reproduce the error. Thank you.

pmundt commented 4 years ago

I hit this while developing a new connector (using the MQTT connector as a base of reference), but the same issue occurs with the in-tree tester, as well (the build of which is currently broken for me, for other reasons).

Before the fix:

$ go run main.go 
2019/12/14 13:41:33 Topic: country-change   Broker: http://adaptant-lab-02:8080
INFO[0000] New 'country-change' subscription: 1b9fdd6f-8b8a-4a66-b0f0-62276389d3b6 
2019/12/14 13:41:33 unexpected end of JSON input
exit status 1

After the fix:

$ go run main.go 
2019/12/14 13:44:40 Topic: country-change   Broker: http://localhost:8080
INFO[0000] New 'country-change' subscription: fb25150c-ee24-49a0-b7ca-7f8900fbe9e0 
2019/12/14 13:44:52 Invoking (http://adaptant-lab-01:8080) on topic: country-change, value: {
    "driverId": 1,
    "entering": "at",
    "leaving": "de",
    "timestamp": "2019-12-12T20:11:12+01:00"
}
2019/12/14 13:44:52 Invoke function: figlet
...

It took a while to figure out exactly where this JSON response was coming from, but I ultimately tracked it down to the namespace unmarshalling in the types package. A curl request on the endpoint confirmed that this was returning 0 bytes, so we've made that check explicit prior to any unmarshalling attempts, which has resolved the matter.

As far as the FaaS Gateway - I've used the latest version from git (as of yesterday) and simply ran the the deploy_stack.sh with no further modification.

alexellis commented 4 years ago

So are you using swarm? @Waterdrips can you check faas-swarm is updated correctly to return an empty set and that the stack is up to date? Cc @LucasRoesler

alexellis commented 4 years ago

What's your connector for btw?

alexellis commented 4 years ago

Released in https://github.com/openfaas-incubator/connector-sdk/releases/tag/0.5.5

pmundt commented 4 years ago

So are you using swarm? @Waterdrips can you check faas-swarm is updated correctly to return an empty set and that the stack is up to date? Cc @LucasRoesler

Yes, this was on Docker Swarm.

pmundt commented 4 years ago

What's your connector for btw?

We have developed a connected car services platform and a number of companion apps (https://knowgo.io), which we are gradually preparing to launch, and are now simply trying to get some of the interfacing components out of the way (OpenFaaS being one of them).

Our current pub/sub interface exposes adaptation events for both our risk and compliance monitoring, as well as for service providers using the platform that need to trigger run-time reconfiguration of either the application or the service deployment. We are likely to expose driver-specific events in this way as well but are more likely to route these through something like beehive or IFTTT (both of which are being tested at the moment).

We are ultimately planning on using OpenFaaS for triggering Edge-based functions within the vehicle, federating this together with fleet and cloud-level OpenFaaS instances, and then begin looking at cross-instance orchestration and deployment (this is largely a byproduct of work we are doing in the SODALITE H2020 project).

I'll send you a better write-up of this for the ADOPTERS document when I have some time.

Waterdrips commented 4 years ago

https://github.com/openfaas/faas-swarm/pull/63

@alexellis ^ PR for the fix in faas-swarm here

alexellis commented 4 years ago

Thank you both

openfaas / connector-sdk