by Jake Dallimore.
Hi Giovana,
That HTTP 100 is almost certainly the reason you're not seeing a successful grade sync. Let's focus on figuring that out.
That message "An HTTP error status was received" is only used when we see a status code above 400. You can see that in this code: https://github.com/moodle/moodle/blob/2dd7290ccbd4057192ba0d695411f62e9f3a2b4d/enrol/lti/classes/local/ltiadvantage/lib/http_client.php#L95-L97. I've had a look at that code, and I think that what's happening here is that we're trying to naively process a response header that looks something like:
HTTP/1.1 100 CONTINUE
HTTP/1.1 4XX SOME_FINAL_ERROR
I can't be certain, of course, but that would explain how the logs show 100, but the exception is being thrown for a 4XX code (the 4xx being fetched via curl's info, the 100 being parsed, incorrectly, from the headers). The header processing code looks for only one HTTP response code on the first line and is picking up the 100 code, and so that's what's being logged. The actual, final response code would be on the line below, which is being obscured. Curl sees the correct final code, but since our client shim doesn't parse the headers correctly, it's reporting that as a 100, instead of the 4xx.
So, I suspect the platform is returning a 4xx error code, but we aren't able to see it because of this buggy client code. This client shim has been replaced in Moodle 4.2, as we now ship the Guzzle library, but in 4.0 and 4.1 this is still going to be a problem. I've created MDL-77990 to address this.
Of course, resolving the above bug will only serve to surface the 'real' error code (which most likely does come from the platform and means there is still a problem we need to look at). Once we know the 'real' error code, we can try to debug further.
If you're able to provide any additional information about the response being sent back from the platform, that would also be very helpful. Are you perhaps using a proxy server somewhere which might add these 100 continues? Anything to understand this further would be helpful.
Thanks again,
Jake
That HTTP 100 is almost certainly the reason you're not seeing a successful grade sync. Let's focus on figuring that out.
That message "An HTTP error status was received" is only used when we see a status code above 400. You can see that in this code: https://github.com/moodle/moodle/blob/2dd7290ccbd4057192ba0d695411f62e9f3a2b4d/enrol/lti/classes/local/ltiadvantage/lib/http_client.php#L95-L97. I've had a look at that code, and I think that what's happening here is that we're trying to naively process a response header that looks something like:
HTTP/1.1 100 CONTINUE
HTTP/1.1 4XX SOME_FINAL_ERROR
I can't be certain, of course, but that would explain how the logs show 100, but the exception is being thrown for a 4XX code (the 4xx being fetched via curl's info, the 100 being parsed, incorrectly, from the headers). The header processing code looks for only one HTTP response code on the first line and is picking up the 100 code, and so that's what's being logged. The actual, final response code would be on the line below, which is being obscured. Curl sees the correct final code, but since our client shim doesn't parse the headers correctly, it's reporting that as a 100, instead of the 4xx.
So, I suspect the platform is returning a 4xx error code, but we aren't able to see it because of this buggy client code. This client shim has been replaced in Moodle 4.2, as we now ship the Guzzle library, but in 4.0 and 4.1 this is still going to be a problem. I've created MDL-77990 to address this.
Of course, resolving the above bug will only serve to surface the 'real' error code (which most likely does come from the platform and means there is still a problem we need to look at). Once we know the 'real' error code, we can try to debug further.
If you're able to provide any additional information about the response being sent back from the platform, that would also be very helpful. Are you perhaps using a proxy server somewhere which might add these 100 continues? Anything to understand this further would be helpful.
Thanks again,
Jake