Thanks for the very detailed description. That certainly helps in tracking stuff like this down. I'm not sure I quite follow their response, though.
beside the normal way to start a new attempt, students have - when set - the possibility to see a result that been send before. Conform LTI we send an earlier used lis_result_source_id without the service url. We don't send the service url because we don't expect a result back.
Assuming you do, could you perhaps clarify what they're trying to say there? It sounds like they're talking about a mechanism to allow grade history to be shown in the Consumer, which can result in a launch with an old lis_result_sourcedid being sent, without an accompanying lis_outcome_service_url. Is that about right?
In any case:
I have no idea how they do it, but could it be that because they don't send the service url again this is being cleaned in the Moodle database?
This seems to align itself with what the tool provider code does. It grabs the service URL and, if different to the currently stored value, it sets the new value.
https://github.com/moodle/moodle/blob/master/enrol/lti/classes/tool_provider.php#L344-L346
I guess this is to handle cases where the service URL changes from one valid URL to another, rather than cases where it's being omitted.
If you have a look at the Basic Outcomes 1.0 documentation (https://www.imsglobal.org/specs/ltiomv1p0/specification), specifically section 2 there, you'll see this part:
A typical implementation pattern is for the Outcomes Service Provider to only accept outcomes for launches with a role of "Learner". If this were the case, the TC would only provide lis_result_sourcedid values on launches with a "Learner" role. If the TC is configured to accept outcomes on a particular launch, the TC is required to include lis_outcome_service_url regardless of the role in the launch and regardless of whether or not a lis_result_sourcedid is included in the launch.
Whilst not exactly the same situation, that, to me, suggests that omitting the service URL isn't something that's permitted when we expect results in any of the launches. Regardless of whether a result is expected on a particular launch, if we expect it at some point, for some role, it seems that the service URL must be sent on every launch.
Hope that helps,
Jake