Decoded USNat string and MSPA values do not match as of 3.1.3 #81
Description
even after setting the MSPA related field values, the resulting GPP string is encoded incorrectly, causing those values to decode as 0's
import { CmpApi, UsNat, UsNatField } from "@iabgpp/cmpapi";
...
cmpApi.setFieldValue(UsNat.NAME, UsNatField.MSPA_COVERED_TRANSACTION, 1);
cmpApi.setFieldValue(UsNat.NAME, UsNatField.MSPA_OPT_OUT_OPTION_MODE, 2);
cmpApi.setFieldValue(UsNat.NAME, UsNatField.MSPA_SERVICE_PROVIDER_MODE, 1);
console.log(cmpApi.getGppString());
In my test case, the cmpApi.getGppString() is returning DBABLA~BVAoAAAAAABk.QA.
Plugging DBABLA~BVAoAAAAAABk.QA into https://iabgpp.com/#DBABLA~BVAoAAAAAAGQ.QA results in all 3 of those MSPA fields to be 0!
This seems to be directly related to this change cba7ad2#diff-4200c161641fdfd9f4669e2edd164388654dcb582d43d7980c26be68f3f9c8e8R96 where extra 0's were added to both the SENSITIVE_DATA_PROCESSING and KNOWN_CHILD_SENSITIVE_DATA_CONSENTS default fields, because reverting that specific change results in the MSPA values to decode correctly. Additionally, with or without reverting that change, the array length returned from https://iabgpp.com/#DBABLA~BVAoAAAAAAGQ.QA in SensitiveDataProcessing is 12 no matter what, and KnownChildSensitiveDataConsents is 2 no matter what. Obviously the encoder is still expecting only those exact number of values.
Those array size changes were probably done for a reason, so I hesitate just reverting that change. I'm continuing to investigate where that change is causing problems and will try to provide a PR soon.