04-20 Uploading Measurements

It turns out that I am not yet finished with uploading measurements.

Problem

I have been trying to get the scannner to upload the queue to the backend using https this afternoon. The client errors out, saying "connection refused". The most peculiar part of this error is that the clientWebservice has no issues whatsoever with registering the client on startup. The measurementWebservice which handles measurement uploads calls the same httpManager.post() request. The only difference in arguments passed to the httpManager is the URI and the request body. I fiddled around with both to no avail, even passing the same values as the clientWebservice.

I then set my focus to the CACertificate, since perhaps it was refusing the connection because the TLS handshake was not successful. This does not seem possible, since the CACertificate worked just fine for registering the client and it was calling the same method.

Then I thought that it possibly was due to weird C++ memory "residue" of an undestroyed object lurking around in memory. I made sure to use delete statements where necessary and set brackets around the blocks that had to sequentially be destroyed before others. This was to no avail.

Solution?

It seems to be that the Webservice cannot be called from inside another class. Invoking one instance of the clientWebservice is fine, since I then have one httpManager instance that interfaces with the hardware. But having many different httpManagers that are invoked at the same time may be causing issues by mutating the same object at the same time.

Possible Fixes

I will think about my options in detail tomorrow but at the top of my head there seem to be 2 viable options:

• make the httpManager a private member of the measurementWebservice and clientWebservice. Calling a private member will encapsulate the code in a container that isnt mutatable from outside. I cannot corrupt the httpManager by creating two of them and mutating them.
• Make the httpManager a public singleton of global scope. This is kind of the opposite of the other option. I then propagate it through the classes using the extern statement. Sounds a bit like an antipattern

THIS WILL NOT FIX THE PROBLEM - Ignore this issue since I will ditch synchronous HTTP as soon as I can anyway. The only reason why I am doing this is because I want to be sure that the backend is ready and can handle incoming requests. I also want to be sure that the ArduinoJson.h lib correctly makes a nested measurements object. Switching to another request "type" will not fix the issue with mutating the same class simultaneously though. I only change the implementation of the code that is being called and mutated twice. I stil invoke undefined behaviour Hmm.