Conflict resolution when the same version of an extension has different metadata on different platforms

[holly-cummins]

At the moment, we do a merge across all PlatformExtension objects to get the client-side data. If an extension has different values for different fields, we take one semi-arbitrarily.

For lists (keywords and extension-dependencies, mostly) we could consider doing a deep merge on the list. For individual values, like status and built-with-quarkus-core, that's not possible.

There are a few options, none great:

• Change the types in the data model to have those fields be lists, and put in everything. It's a bit 'tail wagging the dog', though, since the natural type for the fields is a string.
• Have an optional parameter on the request, which is the platform to favour in the case of conflicts. That's logical, but it's not ideal because it gets us away from the "showing all extensions, independent of platform" goal for extensions.quarkus.io
• Have some sort of visual indicator in the UI that a field has a conflict, and show a drop down/expansion which lists the different values for the different platforms. This seems like the best user experience but it's not totally clear what the back end to support it would be. A map of maps, with platform names as keys?

[holly-cummins]

This also affects https://github.com/quarkusio/registry.quarkus.io/, but I've raised it here so we can decide what we want to show and then work backwards to how we deliver it from the backend.

[maxandersen]

There is also the solution of not trying to merge platforms into the default view about an individual extension.

Then this problem goes away IMO.

We might still have issue about some extensions not providing all metadata that is useful but I would rather fix that than keep making the issue of incomplete data worse.

The platform provided metadata is relevant too but only as "side-info" on what platforms and extension are available in and what the support levels are etc. - which again is purely dependent on what specific platform you choose.

[holly-cummins]

Just to be clear, this isn't platform-provided metadata. This is 'vanilla' metadata for the extension, which may have different versions for different platforms.

Here's an example of the metadata we're looking at:

  "status" : "stable",
      "extension-dependencies" : [ "io.quarkus:quarkus-rest-client", "io.quarkus:quarkus-core", "io.quarkus:quarkus-arc", "io.quarkus:quarkus-resteasy-common", "io.quarkus:quarkus-apache-httpclient", "io.quarkus:quarkus-rest-client-config", "io.quarkus:quarkus-rest-client-jackson", "io.quarkus:quarkus-jackson", "io.quarkus:quarkus-rest-client-jaxb", "io.quarkus:quarkus-jaxb", "io.quarkus:quarkus-jaxp", "io.quarkus:quarkus-keycloak-admin-client-common" ],
      "built-with-quarkus-core" : "3.0.0.Alpha1",
      "categories" : [ "security" ],
      "keywords" : [ "keycloak", "keycloak-admin-client", "admin", "openid-connect" ]

If the status of an extension is different for different platforms, what do we show in the UI? At the moment, we show one of the statuses.

[maxandersen]

"one of the statuses" means what ? there are two kinds. the one in the extension itself, the one that a specific platform version can apply/override.

[holly-cummins]

As I discovered on Friday, the data model isn't actually like that. For extensions which are part of a platform, we accommodate the fact they may have different, extension-specific, metadata for each platform.

To accommodate that, the data model is

ExtensionRelease has a one to many relationship with PlatformExtension, and platform extension is where the metadata specific to that extension lives. So there could be a conflict, because we're collapsing a one-to-many back into a one.

[maxandersen]

yes, so merging is problematic as it can't be done blindly. i.e. absence of status means its stable, thus if you merge blindly by adding the last time status was set you can end up reporting out of date one.

Thus is the better option not to simply just take the "latest" version of extension and use that - and then only show other data from platforms when the UI has some place to show it?

[holly-cummins]

Agreed, we're already taking the latest version of an extension. So the case here is that even for the latest/ a single version of an extension, in the data model, there's a one-to-many relationship to the platforms. Realistically, I suspect it's almost always one-to-one, so conflicts are unlikely.

[holly-cummins]

yes, so merging is problematic as it can't be done blindly. i.e. absence of status means its stable, thus if you merge blindly by adding the last time status was set you can end up reporting out of date one.

Status is a good example of why this work item might be needed. I hadn't thought about the absence of information and you're right that absence of information is also information.

Say extension foobar is released at version 4.2 in two platforms, platform a and platform b (the exact same version in both platforms). So no matter what, we have a problem, because in the data model we have two copies of the metadata, one for each platform. Hopefully, there isn't a conflict. But as you say, if the extension says it's 'preview' in platform 'a' and doesn't list a status in platform 'b', we report the status to 'experimental'. For this example we didn't even notice a conflict but there is a conflict.

[maxandersen]

Exactly - hence I always worked under the assumption that we would pick some strategy for what the "latest" extension would be + github location info and have that be the "default view" and then have a more detailed tab or icons to indicate what versions/variations it is available in.

Much like what npm.js does it. screenshot below is from https://www.npmjs.com/package/homeassistant (arbitrary selected).

Most of this info is AFAIK github info from latest uploaded version which then has its readme.md included and info about versions, stats etc. that goes across releases. imagine it would an extension where it would have a tab called Platforms listing the known platforms its part of where you could then see the exact non-ambigious piece of information.

[holly-cummins]

So this is independent of taking the latest extension, and independent of displaying multiple versions of an extension. The We definitely do display the latest extension. The issue this is covering is that the exact same version of an extension can have multiple copies of its metadata, if that same version of the extension appeared in multiple platforms.

[holly-cummins]

I'll update the issue title to make it clear that the scenario being covered here is the scenario where the conflict is within a single version of an extension. This is something the data model allows, which is why I raised an issue.

[holly-cummins]

Two additional notes:

• Platforms can declare platform-level overrides, which do increase the chances of a conflict when the same version of an extension lives in multiple platforms
• "Choosing the latest" may be the most sensible method for conflict resolution, but it will need a policy for deciding what the latest is. If the platform name is the same we can go by version, if one version of the platform has the "recommended" label, but if the platform name is different and the recommend-status is the same we'd need some policy.