Messages Not Submitting

[ghost]

Have checked SU, Carer and Clinician

No messages submitting.

See https://github.com/healthlocker/healthlocker/issues/915

[ghost]

@katbow @RobStallion to provide time estimate for a fix

[reddog]

@katyedwards Can you provide a little more information on what the block(s) and external dependency are on this issue?

[ghost]

@reddog I don't think there is a blocker or ext dependency - I may have added those to the wrong issue, Friday was a bit manic at times with numerous windows open! Sorry!

[reddog]

@katyedwards No problem - thanks for clarifying.

Are you able to do a test with Chrome's developer console open and paste a screenshot here? That should help determine if it is the same bug as seen in https://github.com/healthlocker/healthlocker/issues/915 If it is the same, then it is an issue related to https://github.com/healthlocker/oxleas-adhd/issues/127

@RobStallion It is possible this could (should?) be fixed in the Phoenix config, see https://github.com/dwyl/learn-phoenix-framework/issues/99#issuecomment-316768858

[ghost]

[reddog]

@RobStallion The websocket HTTP 403 error appears to be the same as in https://github.com/healthlocker/healthlocker/issues/915 :

I'm not sure if the uncaught ReferenceError: Testing is not defined is related or a new error:

The test message that @katyedwards input was Testing so I guess that's the Testing as referred to in the message, but it looks like the code is expecting that to be an object reference of some sort, not the message text content.

[reddog]

@RobStallion Thanks for providing a time estimate. Can you please note what the issue is and what steps are required, breaking anything down that's larger than two hours.

[RobStallion]

I think that this issue is going to be a very similar to hl #915 as pointed out by yourself and @katyedwards. To try and resolve this I am going to follow the steps taken by @nelsonic when he submitted hl pr #936.

This will mean updating the nginx config on the server which may have unforeseen issues. Also if the the solution used in the PR mentioned above does not work then it will require time to further debug and then resolve.

[reddog]

@RobStallion Thanks for that.

Are you referring to the nginx config change that @nelsonic referenced here: https://github.com/healthlocker/healthlocker/issues/841#issuecomment-316759183

It looks like this might also be solved by a change to the Phoenix configuration, see https://github.com/healthlocker/healthlocker/issues/841#issuecomment-316769461

If it is fixable in the Phoenix configuration then it would be fixed for anyone else doing a deployment somewhere else, another fork, etc.

Is that worth considering?

[reddog]

See the issue over on the Dwyl Learn Phoenix repo for the possible Phoenix configuration change that may well fix this up, and then make the fix available for future forks / deployments, etc, see https://github.com/dwyl/learn-phoenix-framework/issues/99#issuecomment-316768858

[RobStallion]

@reddog Thanks for pointing that out. I will try this solution first and will update the issue with how it went.

To expand on what I said here regarding time estimate for this issue. As we discussed in person, this issue could be as quick as T1h if the solution @nelsonic used when he originally fixed this issue in hl pr #936 (or now the solution that you suggested above) works on the first attempt. However, the reason that the estimate has been put at T1d is as a precaution. If those solutions do not work then we will need time to debug the issue and try to find a solution.

[ghost]

Tested for clin, SU and Carer - all good!

[RobStallion]

This issue was resolved with the same nginx fix that @nelsonic used in his hl pr #936. @reddog could you please say if this is ok or would you still like us to implement the fix you suggested here

[reddog]

@RobStallion Thanks very much for fixing this up.

As we discussed, I think part of the reason that this issue reoccurred after it was first fixed was that the nginx config was (able to be?) re-used for the previous repo.

Can you please give a little detail (a line or two) on how we are, or how we could, prevent this from happening again, ie how can the nginx config be (automatically?) used in a future deployment.

[iteles]

@reddog This is to be covered in #191

[reddog]

@iteles #191 is titled "documentation" - wasn't sure if that covered scripts being available, etc? I don't know if this issues occurred due to a lack of previous documentation or something missing/not in the repo, etc

[ghost]

FYI, messaging is working fine on the live site, thanks @RobStallion

[RobStallion]

@reddog I am closing this issue as the solution to the problem is now also listed in the documentation.