Ambiguity in NpgsqlArrayValueConverter Causes Test Failures on Mono Runtime

[medhatiwari]

Description

The following test cases fail in the test/EFCore.PG.Tests/ suite when run on the Mono runtime:

1. NpgsqlArrayValueConverterTest.Can_convert_number_arrays_to_enum_arrays_object
2. NpgsqlArrayValueConverterTest.Can_convert_number_arrays_to_enum_arrays
3. NpgsqlArrayValueConverterTest.Can_convert_enum_arrays_to_number_arrays
4. NpgsqlArrayValueConverterTest.Can_convert_enum_arrays_to_number_arrays_object

fails on the Mono runtime, even though it passes on CoreCLR. This issue arises due to differences in how the Mono runtime and CoreCLR handle Type.GetInterfaces() for arrays or collections.

A similar issue has been reported in the .NET Runtime repository:
Mono ves_icall_RuntimeType_GetInterfaces generates an extra Implemented Interface (#108964).
Referencing this issue, Mono generates additional generic interfaces that lead to ambiguity in certain scenarios.

Reproducible Example

Program.cs

using System;
using System.Collections;
using System.Collections.Generic;
using System.Linq;

public enum Beatles
{
    John = 7,
    Paul = 4,
    George = 1,
    Ringo = -1
}

public static class Program
{
    public static void Main(string[] args)
    {
        var beatlesArray = new Beatles[] { Beatles.John, Beatles.Paul };
        var beatlesList = new List<Beatles> { Beatles.John, Beatles.Paul };

        Console.WriteLine($"Array Type: {beatlesArray.GetType()}");
        Console.WriteLine($"List Type: {beatlesList.GetType()}");

        Console.WriteLine("Checking implemented interfaces for the array...");
        CheckImplementedInterfaces(beatlesArray);

        Console.WriteLine("Checking implemented interfaces for the list...");
        CheckImplementedInterfaces(beatlesList);

        Console.WriteLine("Comparing equality:");
        try
        {
            AssertEqual(beatlesArray, beatlesList);
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Equality check failed: {ex.Message}");
        }
    }

    private static void CheckImplementedInterfaces(object obj)
    {
        var enumerable = obj as IEnumerable;
        var implementedInterfaces = enumerable?.GetType().GetInterfaces();

        foreach (var iface in implementedInterfaces ?? Array.Empty<Type>())
        {
            Console.WriteLine($"  - {iface}");
        }
    }

    private static void AssertEqual(IEnumerable expected, IEnumerable actual)
    {
        var expectedList = expected.Cast<object>().ToList();
        var actualList = actual.Cast<object>().ToList();

        if (!expectedList.SequenceEqual(actualList))
        {
            throw new Exception($"Collections differ:\nExpected: {string.Join(", ", expectedList)}\nActual: {string.Join(", ", actualList)}");
        }

        Console.WriteLine("Collections are equal!");
    }
}

Analysis

Behavior on CoreCLR

The output of GetInterfaces() for Beatles[] on CoreCLR:

Checking implemented interfaces for the array...
  - System.ICloneable
  - System.Collections.IList
  - System.Collections.ICollection
  - System.Collections.IEnumerable
  - System.Collections.Generic.IList`1[Beatles]
  - System.Collections.Generic.ICollection`1[Beatles]
  - System.Collections.Generic.IEnumerable`1[Beatles]
  - System.Collections.Generic.IReadOnlyList`1[Beatles]
  - System.Collections.Generic.IReadOnlyCollection`1[Beatles]

Behavior on Mono

The output of GetInterfaces() for Beatles[] on Mono:

Checking implemented interfaces for the array...
  - System.Collections.ICollection
  - System.ICloneable
  - System.Collections.Generic.ICollection`1[System.Int32]
  - System.Collections.Generic.IList`1[System.Int32].         
  - System.Collections.Generic.ICollection`1[Beatles]
  - System.Collections.Generic.IList`1[Beatles]
  - System.Collections.IEnumerable
  - System.Collections.Generic.IReadOnlyCollection`1[System.Int32]
  - System.Collections.Generic.IReadOnlyCollection`1[Beatles]
  - System.Collections.Generic.IReadOnlyList`1[System.Int32]
  - System.Collections.Generic.IReadOnlyList`1[Beatles]
  - System.Collections.IList
  - System.Collections.IStructuralComparable
  - System.Collections.IStructuralEquatable
  - System.Collections.Generic.IEnumerable`1[System.Int32]
  - System.Collections.Generic.IEnumerable`1[Beatles]

The additional System.Collections.Generic.IEnumerable<int> interface in Mono leads to ambiguity in identifying the correct element type for TryGetElementType.

Expected Output

The correct element type for the Beatles[] array should be typeof(Beatles).

Actual Output on Mono

Ambiguity arises when TryGetElementType internally retrieves interfaces. Mono includes:

• IEnumerable<int>
• IEnumerable<Beatles>

The function cannot resolve which interface is relevant, causing it to fail.

Root Cause

The Type.GetInterfaces() API (via Mono's ves_icall_RuntimeType_GetInterfaces) generates an extra generic interface for arrays (e.g., IEnumerable<int>), which is not present in CoreCLR. This discrepancy causes TryGetElementType to fail due to ambiguous matches.

Observed Behaviour [src/Shared/SharedTypeExtensions.cs]

here

Type? singleImplementation = null;
foreach (var implementation in types)
{
    if (singleImplementation is null)
    {
        singleImplementation = implementation;
    }
    else
    {
        singleImplementation = null;
        break;
    }
}

This logic:

1. Selects the first match (singleImplementation = implementation).
2. If a second match exists, invalidates the result by setting singleImplementation = nul

Issue : On Mono, where extra interfaces exist (e.g., IEnumerable), this logic discards the valid interface (IEnumerable), leading to incorrect results.

Proposed Fix

public static Type? TryGetElementType(this Type type, Type interfaceOrBaseType)
{
    if (type.IsGenericTypeDefinition)
    {
        return null;
    }

    var types = GetGenericTypeImplementations(type, interfaceOrBaseType);

    if (!types.Any())
    {
        return null;
    }

    if (type.IsArray)
    {
        var elementType = type.GetElementType();
        if (elementType != null)
        {
            var arrayCompatible = types.FirstOrDefault(t => t.GenericTypeArguments.Contains(elementType));
            if (arrayCompatible != null)
            {
                return arrayCompatible.GenericTypeArguments.First();
            }
        }
    }

    return types.First().GenericTypeArguments.FirstOrDefault();
}

Justification for the Fix

The updated implementation resolves ambiguity for arrays more reliably by:

1. Narrowing Down to Compatible Interfaces:
   var arrayCompatible = types.FirstOrDefault(t => t.GenericTypeArguments.Contains(elementType));
   This checks each interface in types and selects the first interface whose generic arguments contain the array's element type (e.g., Beatles for Beatles[]).

2. Prioritizing Array Compatibility: If a compatible interface is found (e.g., IEnumerable<Beatles>), it is returned immediately. This ensures the method prefers interfaces that match the array's actual element type.

3. Fallback to First Interface: If no specific array-compatible interface is found, the method defaults to the first interface in types. While not ideal, this ensures the method still functions and prevents errors in cases where no clear match exists.

Example

For the type Beatles[], Type.GetInterfaces() on Mono returns:

• IEnumerable<int>
• IEnumerable<Beatles>

The updated method:

1. Detects that the array's element type is Beatles.
2. Loops through types to find the first interface whose generic arguments include Beatles:
3. IEnumerable<int>: No match (int ≠ Beatles).
4. IEnumerable<Beatles>: Match found!
5. Returns IEnumerable<Beatles> as the resolved type.

This fix resolves test failures specific to Mono while maintaining compatibility across CoreCLR. This change ensures consistency in behavior and resolves ambiguity introduced by Mono's interface resolution logic.

@uweigand @giritrivedi @saitama951

[roji]

Thanks for this, but isn't this something that needs to be fixed on the mono side? Libraries shouldn't start having to change code to accomodate mono discrepancies, no?

[giritrivedi]

Thanks for this, but isn't this something that needs to be fixed on the mono side? Libraries shouldn't start having to change code to accomodate mono discrepancies, no?

@roji , Yes you are right. This is just a work around. A better fix will be given in Mono.