tweag / nickel

Better configuration for less
https://nickel-lang.org/
MIT License
2.43k stars 93 forks source link

Multiple contracts on a record not working as intended #2041

Closed alialabbas closed 2 months ago

alialabbas commented 2 months ago

Describe the bug Typically, the following code would apply multiple contracts on a value and if value is a negative number it would fail on the second part of the contract.

-123 | Number | std.number.PosNat 

However, this is not the case when applying multiple record contracts and both have the same set of fields. The snippet below should have failed when evaluating container but it doesn't. Based on my testing, this only happens when both inner and outer have the same of fields and adding an additional field to either contracts would give the expected behavior.

let outer = {
  spec
    | {
      hostAliases | Number | optional,
      containers | Number | optional,
      ..
    }
    | optional,
  ..
}
in
let inner = {

  spec
    | {
      hostAliases
        | optional,
      containers
        | Array {
          ..
        },
      ..
    }
    | optional,
  ..
}
in
{
  spec = {
    hostAliases = "this should have failed",
    containers = [
      {
        name = "test",
        image = "nginx",
        ports = [
          {
            containerPort = 80,
            name = "http"
          }
        ],
      }
    ]
  }
} | inner | outer 

Expected behavior {} | contract1 | contract2 should work when both contracts run checks against the same set of fields.

Environment

yannham commented 2 months ago

Thanks for the report. I can reproduce on 1.8.0, and the optional don't play any role here - the bug still happens if we remove them all. The .. are also not necessary for the repro. The bug was already present in 1.7.0 and 1.6.0. I'll bisect to see when it started, but I think we should make a minor release once it's fixed - silently ignoring contracts is bad.

Given the fact that adding a field to either record fixes the issue, I'm highly suspecting that the contract deduplication optimization isn't sound and consider the two contracts to be equivalent for some reasons, thus eliding the second one.

yannham commented 2 months ago

(Note: first bad commit is 2a727baaea35ba88852fe05ef4ab91355b666031, which does touch the record contract equality code to ignore pending contracts)