@pld I think this would be a good addition to the FHIR Core app too. We can make it configurable with an opt out capability.

kinda agree! but.. what happens if they are invalid? once someones trying to store a resource we wouldn't want to not persist it, I guess in theory we could redo the extraction after the config has been updated, like you could mark the QR as extraction pending or something.

But I feel like the more impactful place for effort would be on validating structuremaps to ensure they are only producing valid resources as outputs

Suppose we had a variant of this that only makes this type of validation check mandatory for Debug mode. That way during development it is easier for engineers to catch such early on. This can be in place regardless of the conclusion we make for this ticket.

@ndegwamartin I agree this is more for the development stage and not necessary for use in production. The assumption here is that all SMs and CQL would generate correctly formatted resources by the time an app goes live

@LZRS how far are we with this? cc @ndegwamartin

@LZRS how far are we with this? cc @ndegwamartin

With this PR the validation of resources for debug, before saving to db, was added but ran into issues to do with dependency incompatibilities for the caffeine library that was causing the app to crash whenever a validation happened

Replacing the caffeine library caching with guava, using the latest engine sdk artifacts, fixes the issue but it means work on validation essentially depends on the work/merge of #2825

The validation checks that the FHIR resources conform to the defined structure, references match the expected types (that is, without checking if they refer to non-existing resources) and that code systems used are known (although, for now, marked as just warnings). Failed validations are logged to logcat, and questionnaire submission fails to succeed until all validations pass (while in debug)

Pending enhancement, would be to allow skipping to submission anyways, as some errors of validations could be treated with leniency

@LZRS can we show the user the failed validation directly on the screen in a way they can copy it? the users of debug will be testers on our and other teams so their workflow will be

1. submit form
2. get error
3. copy error data into new issue

I think your suggestion is brings up a very good point. If the tester hits a non-critical error, we don't want them to be unable to continue testing until that non-critical error is resolved. How about we show the error in a very big clear way so the tester knows to create an issue, but we continue with the submission so that they can continue testing the workflow.

Yeah, makes sense. I will be looking into maybe showing the errors in a dialog just before continuing with submission. The dialog would allow the users to copy the errors and also probably have an extra button to either allow to share the errors (maybe to slack, github or email) or do background submission of the errors to sentry, email or even github