entry_information not stored owing to bug in dallinger2.js

Extra URL parameters are meant to be stored in Participant.entry_information. Currently this fails (tested with the bartlett1932 demo).

The error appears to be in dlgr.createParticipant:

  dlgr.createParticipant = function() {
    var url = "/participant";
    var data = {};
    var deferred = $.Deferred();

    if (dlgr.identity.assignmentId) {
      url += "/" + dlgr.identity.workerId + "/" + dlgr.identity.hitId +
            "/" + dlgr.identity.assignmentId + "/" + dlgr.identity.mode + "?fingerprint_hash=" +
            (dlgr.identity.fingerprintHash) + '&recruiter=' + dlgr.identity.recruiter;
    } else {
      data = dlgr.identity.entryInformation;
    }
...

Looking at this, we see that if dlgr.identity.assignmentId is truthy, then the URL is constructed from dlgr.identity, ignoring the entry information.

We therefore have a hack in our own code that temporarily sets dlgr.identity.assignmentId to null to avoid this behaviour:

{% block scripts %}
{{super()}}
    <script>
        dallinger.identity.participantId = "undefined";

        let assignmentId = dallinger.identity.assignmentId;
        dallinger.identity.assignmentId = null;

        dallinger.createParticipant().done(function(resp) {
            setTimeout(function() {
                let participantId = dallinger.identity.participantId;
                dallinger.identity.assignmentId = assignmentId
                dallinger.goToPage("timeline/" + participantId + "/" + assignmentId);
            }, 500);
        }).fail(function(resp) {
            dallinger.error(resp);
        });
    </script>
{% endblock %}

However, I believe that the issue should really be addressed in dallinger2.js. I don’t really understand the logic for why there are two versions of the URL construction procedure depending on whether dlgr.identity.assignmentId is initialised or not, but in any case, the logic between these two versions should be consistent.

Perhaps it would be worth additionally adding a test to ensure that entry_information really is registered properly?

[jessesnyder]

I’m wondering if we should raise an error in any route that calls exp.normalize_entry_information() if the return value doesn’t fulfill the contract, rather than shuffling on and failing in various ways later?

“The normalize_entry_information() method on experiment {exp.class.name} was called with {json.dumps(entry_information)} and returned {json.dumps(result)}, which does not fulfill the contract for this return value. The returned data structure must include the keys: assignment_id, worker_id, and hit_id.”

Something like that.

[alecpm]

I think the idea was that assignment_id in the initial request meant that you were using the new entryInformation approach and assignmentId in the request initiated the old approach. That is a bit implicit, but the intent was to provide a new way while providing backwards compatibility. Not sure what the best fix would be beyond using assignment_id in the ad urls in experiments that want to use the entryInformation approach.