12.1p DSRequest "unknown outputs"-warning improvement

[Blama]

Hi Isomorphic,

I'm getting this warning in my server logs (v12.1p_2022-03-16 but if this also affects 12.0p, could you change it there as well?):

WARN com.iso.dat.DSRequest [https-openssl-nio-443-exec-6] The dsRequest contains a client-specified 'outputs' which contains a reference to a field that is not on this DataSource and is not a dynamic reference to a field on another DataSource.  Ignoring the client-specified value

This seems strange to me, as the request in question does not use a clientside outputs.
The .ds.xml operationBinding does this though, but all fields in question are fields of the DataSource:

<operationBinding operationType="fetch" operationId="fetchCount" serverMethod="fetchCount" outputs="LEAD_ID, STATUS_SHORTNAME, STATUS_POSITION, STATUS_PICKED">
            <summaryFunctions>
                <LEAD_ID>count</LEAD_ID>
            </summaryFunctions>
            <groupBy>
                <groupByField>STATUS_SHORTNAME</groupByField>
                <groupByField>STATUS_POSITION</groupByField>
                <groupByField>STATUS_PICKED</groupByField>
            </groupBy>
</operationBinding>

Could you improve the logged warning so that this also mentions the field(s) the framework is unhappy about? This way I might get closes to the real issue of this possibly bogus warning.

Thank you & Best regards
Blama

[Isomorphic]

Sure - we've added the unrecognized field name to the warning.
Try the next nightly build (dated April 12 or above)

Regards
Isomorphic Software

[Blama]

Hi Isomorphic,

thanks, that helped. I had a DMI with an aggregation fetch - that fetch was fine.
After that I did another fetch in the same DMI with the rpcManager from the request. This 2nd fetch had a typo in one field name, that caused the issue.
As the initial request was from the client, and the rpcManager was also used for the 2nd request, the warning included "...client-specified..." which mislead me. I'm not sure this is an issue worth fixing, but it might be.

Also, I did not have any data problems, as the as fields were fetched ("Ignoring the client-specified value").
I did not test what happens for broken serverside outputs, but I think this fallback to "all fields" would be a good addition to clientside and/or serverside DSRequest.setOutputs() docs.

Best regards
Blama