Snapshot generator calculates invalid max cardinality for extensions

[Rob5045]

A bug has been reported for Forge:
https://firely.atlassian.net/browse/FOR-611

When adding a new extension to a profile, save it and reload it, the max cardinality is set to "*" while "1" is expected.

I have created a unit test in this branch (based on 3.8.0 R4 release) to reproduce the problem:
https://github.com/FirelyTeam/firely-net-sdk/tree/forge/FOR-611

The expected behavior is that the BaseElement and derived element contains the correct max cardinality.

FHIR Version: R4 (may apply to other versions as well)
SDK Version: 3.6.0 and newer (works as expected in version 3.4.0!)

[ewoutkramer]

Unfortunately, the SDK team does not maintain the snapshot generator anymore since 2022-02-20. We are contemplating restoring the original situation where the Forge team was responsible for its maintenance 🤣

[Rob5045]

As of 2022-02-20 I have secretly joined the Simplifier team!

[Rob5045]

As per response from Ardon this problem is a showstopper for the upcoming Forge 28.0 release.

[ewoutkramer]

Since the show must go on, I'll flag this issue.

[marcovisserFurore]

I am browsing the release notes between 3.4 and 3.6, but I have not seen a smoking gun yet. But we will find it :)

[ewoutkramer]

When adding a new extension to a profile, save it and reload it, the max cardinality is set to "*" while "1" is expected.

Why is the "1" expected? I followed the link to the issue in Forge, but that only contains a screenshot, so it was not clear to me what is actually wrong with it.

[Rob5045]

The extension has a cardinality of 0..1 so when you use it in a profile the "base element" should have a cardinality of 0..1 as well. However after the snapshot generator does its thing, it has a cardinalty of 0..* (see the unit test in the branch https://github.com/FirelyTeam/firely-net-sdk/tree/forge/FOR-611). When you run this unit test from the 3.4.0 branch it is green. When run from 3.8.0 it is red.

[marcovisserFurore]

I found the culprit. The PR #1826 changed this behavior and @ewoutkramer already warned for that: #1826 (comment).

The proposed solution (the higher one of the min and the lower one of the max) is working for the max, but not for the min . I am looking for a better solution, but the good news is that we found the place to fix it.