On posting to new site getting 500 response #538
Comments
|
@neilh10, thanks for this detailed report. We'll look into it. |
|
thanks. |
|
I'm still getting the problem on posting to test08. Should I rebuild another site? [2021-12-16 13:28:12.807] Connected Internet |
|
Thanks @neilh10, I'll reopen this and take a closer look. |
|
Thanks for following up on this. I didn't understand the initial scope of this issue, but I think I've sorted it now. This was a database related issue. Some where (I assume in the migration process) the resultid for '3bebd4a3-8b54-4f92-ba55-5fd2fd021358' went missing from the timeseriesresults table. A missing resultid meant that the query, associated with the post request you included above, would return an exception for a foreign key violation. Per our implementation of the fix to #510, you now receive a 500 response when the post encounters an exception. Good to know the solution is working and the post will no longer silently fail by returning a 201. This issue looks to have been relatively narrow in impact. There were only 2 sensors affected. Let me know if you're still seeing 500 responses, but I think I can close this one for now. |
|
@ptomasula this site was only created yesterday, so something in perhaps in the site creation process. So good to hear #510 is working correctly responding with "500 Internal Server Error" For my test site test08 So the new record POST is succeddeding, So just looking at the SampleNumber in the trace below [2021-12-16 15:12:12.760] Connected Internet |
|
@neilh10 Thanks for the additional information. Good to know this was a site that was created yesterday. I'll review the site creation code and verify that is it correctly populating the tables. This behavior might be related to the dead TSA code above, but either way that's a good thought as to the cause. I think the 500 response for the secondary post is also related to the handling of #510. The data in that post appears to already be on the server. For example sensor a0e41a66-875a-44fc-9e2f-02c6e25f6063 already has a record at 2021-12-15T13:12:11-08:00 When that second POST request is processed, the query will return a primary key violation because the combination of sensoruuid and timestamp are non-unique (because they are already in the database). This cause the code for #510, which handles any database related exception, to return a 500 response. Maybe more sophisticated exception handling is needed, like returning a different 500 code for duplicate primary keys. |
|
@ptomasula thanks for the diagnosis. So that was my guess for the second POST that it was matching it to what's in the database. Why would that be identified problem?. Shouldn't the logic be to say yes its received, and then its in the database, so return everything successful. From communications theory, the communications channels are imperfect, and there is always a chance no matter how perfect everything is designed that the source Mayfly may not get a 201 to everything it posts. I've floated discussions for #485 and #524 very standard issues in multi computer systems. |
Previous implementation of #510 meant that any database related exception would result in 500. As suggested in #538, duplicate data being sent to the server does not necessarily constitute an error from the external perspective. This commit introduce code that pass on exceptions for primary key violations (duplicate resultid and datetime) and will still return a 201.
|
Thanks @neilh10 I agree with you and have revised the logic to pass over exceptions for duplicate primary keys. It will instead, as a shortish term fix, return a 201 response when duplicates are passed. There might be, as you pointed out, a more appropriate and informative response code like 208 that we should be returning instead. Though we'll probably need to wait until we clean up the code base a bit further to implement more advanced logic. Hopefully this solution gets your algorithm up and working for now. I'm also glad you are thinking about algorithm stability. I think keeping #485 and #524 open as a place holder for that discussion makes sense. |
|
@ptomasula ~~~yeah~~~~ working My test08 systems is now receiving an occasional 504's, (possibly less than 1 in 200), and thats probably everything working correctly My test06 system is still however now receiving too many 504's to be workable. It was working before the upgrade. Possibly an issue to do with #504 lurking here. See below. For the record test08 is my desk based Mayfly 0.5b ModularSensors based 0.30.0 my fork build, that is running over wiFi S6B with my fork of TinyGSM 0.11.5 [NETWORK] My test06 is a longer term stability, using Mayfly 0.5b ModularSensors version 0.32.2 over an LTE CAT-M1 verizon modem. I re- started it [2021-12-16 11:47:39] Here is the latest POST - which is consistent with its previous few cycles (its POSTing over verizon every 10minutes, with 5 readings each time) Its getting 504's from the 2nd post. So trying to decode it, I believe I'm opening the TCP/IP doing all POSTs for new readings this cycle even if non-201 is received, and then closing the TCP/IP. |
|
oops I take it back test06 is uploading now [2021-12-17 12:46:11] Waiting up to 15000 ms for Digi XBee3 Cellular LTE-M to respond to AT commands... .... [2021-12-17 12:57:58] POST /api/data-stream/ HTTP/1.1 still going strong. Something cleared - thankyou thankyou |
|
It POSTED 5+100 readings successfully, [2021-12-17 13:20:12] after that of the first 5 readings, 3 got 504's and the last was 201 - so its uploaded 100 records out of the QUE ok. So it seems to me there is something indeterminate happening, just don't know how to characterize it. I checked the paceing and its 1000mSec, so maybe I should change it to 3000mSec to see if it makes a difference. so completed the upload. |
|
@neilh10, think it is worth changing your host to See my explanation here. |
For a new site I've created, it only seems to get a response of 500.
https://monitormywatershed.org/sites/tu_rc_test08/
The new site creation had some errors in the process of setting it up, but seems to be functional - #537
However the data does seem to be showing up as seen by the Sequence Number incrementing.
The mayfly test08 POST looks like this
.....
and every POST
The text was updated successfully, but these errors were encountered: