Runner stops after first iteration when no output fields are set

[jreyesr]

Reported by @dotJson in #3

I find if I dont set an output map in the batch dialog it does not iterate through the CSV so I have been selecting bogus fields to get it to go. if it, as you say should work without defining an output, then something is stopping my runners after the first iteration. I have been setting it to some random selection in the CSV headers and typing garbage in the JSON path field to get it to go.

[jreyesr]

Steps to reproduce:

1. Set up a request, include at least a placeholder template tag
2. Open the Batch Requests dialog, load a CSV file
3. ⚠ Don't set even one Output, this is what triggers the bug
4. Click the Run button

Result:

1. First request runs and the progress bar updates to 1/N
2. No more requests are sent afterwards
3. No error dialog is displayed
4. The DevTools console (shown by pressing Ctrl+Alt+I) prints a log: The "path" argument must be of type string or an instance of Buffer or URL. Received undefined

[jreyesr]

However, other times it does work correctly when no Outputs are set

[dotJson]

The stopping issue does appear to be related to XML in the response. Unfortunately I have to use the XML API for some calls.

[dotJson]

Also, I figured out the scenario a bit further. When API responds with XML, if you do not set outputs then it completes and halts after 1 iteration, and does not pop the alert about incorrect content-type. As if it halts before the alert call. However, if you set an output, the iterations do not stop but the alert pops. So it seems if allowing XML responses (by testing and bypassing any JSON evaluation?) would enable iterations to continue without having to set outputs.

UPDATE: I moved around some lines in main.js to get it to bypass JSON path and it iterates.

if (outputConfig.length > 0 && response.contentType.startsWith("application/json")) { //context.app.alert("Error!", The response has invalid Content-Type "${response.contentType}", needs "application/json"! Alternatively, delete all Outputs and try again.); // continue; // There's no point in attempting to parse the response, just jump to the next request // Read the response data, then apply JSONPath expressions on it and update the CSV data const responseData = JSON.parse((0, $d7c7cb7a1f9a8455$export$889bdc5a16325af3)(response.bodyPath)); console.debug(responseData); for (const { name: name , jsonPath: jsonPath } of outputConfig){ let out = (0, $d7c7cb7a1f9a8455$export$7419b2935890b5eb)(jsonPath, responseData) ?? null; console.debug(name, "+", jsonPath, "=>", out); let nextData = [ ...csvData ]; // Copy the array so that it can trigger a state update out = JSON.stringify(out); // BUGFIX: If value was a string, remove the quotes, since they look weird, and we expect strings to be one // of the primary output values of the plugin if (out.startsWith('"') && out.endsWith('"')) out = out.substring(1, out.length - 1); nextData[i][name] = out; // Mutate the required field, save it as a string } // // Read the response data, then apply JSONPath expressions on it and update the CSV data // const responseData = JSON.parse((0, $d7c7cb7a1f9a8455$export$889bdc5a16325af3)(response.bodyPath)); // console.debug(responseData); // for (const { name: name , jsonPath: jsonPath } of outputConfig){ // let out = (0, $d7c7cb7a1f9a8455$export$7419b2935890b5eb)(jsonPath, responseData) ?? null; // console.debug(name, "+", jsonPath, "=>", out); // let nextData = [ // ...csvData // ]; // Copy the array so that it can trigger a state update // out = JSON.stringify(out); // // BUGFIX: If value was a string, remove the quotes, since they look weird, and we expect strings to be one // // of the primary output values of the plugin // if (out.startsWith('"') && out.endsWith('"')) out = out.substring(1, out.length - 1); // nextData[i][name] = out; // Mutate the required field, save it as a string setCsvData(nextData); }

[jreyesr]

OK. It's definitely due to XML then.

Indeed, if you do not set any outputs, the check for Content-Type JSON does not trigger (in 3), but then it goes ahead and tries to parse the body as JSON anyways (in 5), and that's killing your process. If you set at least one output, it enters (3), gives an alert but then bypasses the rest of that iteration and doesn't even try to parse it as JSON.

That should be easy to fix, by changing that logic around a bit and only making it parse the response when both a) you have requested at least one output AND b) the response returns a JSON contenttype. That will forbid extracting any information from non-JSON responses, but as I understand it you don't need it anyway, you're just calling the API for its side effects.