[karlnaden]

Summary

This PR adds tests for FHIR Subscription update (PUT and PATCH (json)) and delete transactions to both the Subscriptions client and server tests.

Additionally it

• upgrades to the latest version of inferno_core
• updates the client suite Subscription endpoints to return FHIR OperationOutcomes
• adds "no_custom_extension" validator definitions so that when testers provide content (Subscription for server tests, Notifications for client tests) custom extensions are not allowed.

Testing Guidance

• Run the client and server tests against each other to demonstrate the update and delete tests.
• Add custom extensions to the Subscription and Notification and confirm that
  • The Subscription extensions cause errors on the server tests but only warnings on the client tests
  • The Notification extensions cause errors on the client tests but only warnings on the server tests

[ljtucker]

.first returns the oldest successful Subscription creation in the session. The group description says to re-run "Demonstrate the Subscription Workflow" before re-running this group. But after that re-run, .first still points at the Subscription this group already deleted. So the PUT test's read gets a 404/410 and fails.

The subscription_creation tag is also shared with the event-notification groups, so this isn't necessarily the workflow group's Subscription anyway. Could this use .last, with the descriptions changed to say "the most recently created Subscription"? A spec for the re-run case would be good too.

Suggested change

	JSON.parse(creation_requests.first.response_body)['id']
	JSON.parse(creation_requests.last.response_body)['id']

[karlnaden]

addressed - add a specific "workflow" tag so that there's only ever one subscription tagged in this way and added a spec test to help ensure future updates don't change that.

[ljtucker]

parse_json_patch only checks that each operation has a string op. Hana reads value and from with Hash#fetch, so a patch like [{"op":"add","path":"/reason"}] raises KeyError. That isn't rescued here, so the client gets a 500 instead of a 4xx. Could we add KeyError to the rescue and add a spec for a missing value?

Suggested change

	rescue Hana::Patch::Exception, Hana::Pointer::Exception => e
	rescue Hana::Patch::Exception, Hana::Pointer::Exception, KeyError => e

[karlnaden]

There were other potential issues that didn't raise a KeyError, so implemented this with some manual checks before sending to Hana in added a broad rescue around it.

[ljtucker]

All changes look good. There was one error on the testing scenario "Notification bundle extensions should cause errors in Client Suite but Warnings in Server Suite" as seen above, but given that the error was specifically about my use of a dummy URL, not sure if it really applies.

[karlnaden]

All changes look good. There was one error on the testing scenario "Notification bundle extensions should cause errors in Client Suite but Warnings in Server Suite" as seen above, but given that the error was specifically about my use of a dummy URL, not sure if it really applies.

Reproduced that server suite error and it is mirrored on the client suite with the additional "no custom extensions" error, so it is fine.