This is from RT #80632. If you import a MP file that has active qualification events that are missing either the monitoringQualificationLEEData or monitoringQualificationLMEData properties then the import will fail with this error:
Cannot read properties of undefined (reading 'forEach').
The problem is in the import checks. They are trying to access these properties even if they don't exist in the incoming file.
https://github.com/US-EPA-CAMD/easey-monitor-plan-api/blob/e773cb22a37e836a5a0a5b8776486f9694ae7068/src/monitor-qualification-workspace/monitor-qualification.service.ts#L104
We've run into numerous issues like this where a property is defined as optional in the schema, but if it's left out of the file the import code blows up. Can we search all of this code and look for unsafe access? I'm sure there are some linter rules that will help here.
See the following comments for lists of all fields in the JSON that are optional and should be checked for unsafe access.
Please note that required primitive fields that may have a null value are not included in these lists. For the scope of this ticket, we assume such cases are already correctly handled.
The version field is currently listed as optional in the schemas, but enforced as required in the APIs. It should, in fact, be required, and the schemas should be updated to reflect that.
This is from RT #80632. If you import a MP file that has active qualification events that are missing either the monitoringQualificationLEEData or monitoringQualificationLMEData properties then the import will fail with this error:
Cannot read properties of undefined (reading 'forEach').
The problem is in the import checks. They are trying to access these properties even if they don't exist in the incoming file.
https://github.com/US-EPA-CAMD/easey-monitor-plan-api/blob/e773cb22a37e836a5a0a5b8776486f9694ae7068/src/monitor-qualification-workspace/monitor-qualification.service.ts#L104
We've run into numerous issues like this where a property is defined as optional in the schema, but if it's left out of the file the import code blows up. Can we search all of this code and look for unsafe access? I'm sure there are some linter rules that will help here.
See the following comments for lists of all fields in the JSON that are optional and should be checked for unsafe access.
Please note that required primitive fields that may have a
nullvalue are not included in these lists. For the scope of this ticket, we assume such cases are already correctly handled.The
versionfield is currently listed as optional in the schemas, but enforced as required in the APIs. It should, in fact, be required, and the schemas should be updated to reflect that.