Samir Talwar

I have managed to make the time to sort out those vaguely-related issues. The next challenge is picking a regex engine. I was hoping to support Perl-compatible regular expressions (PCRE)...

I've been digging into this and it seems quite clear that this is caused by a failure to invalidate the relevant parts of the schema cache upon replacing the metadata....

I tried digging into the thought process behind `replace_metadata` but didn't find too much; I think tacit knowledge is going to get us further than Git history in this case.

> The inconsistencies raised by migrations normally get resolved after the final `hasura metadata apply`. So what causes this to normally work as expected, but fail in the case reported...

I think there are two issues here. The first is the one pointed out by @scriptonist. I think that it can be summarized as follows: `replace_metadata` should have the effect...

@scriptonist, I have resolved this in https://github.com/hasura/graphql-engine/commit/93e8803d3e1cc4650229f3764743697abefc2665. happy to close this out now?

I think this is pretty sensible! It's especially pertinent as we use Git inside some of our test cases, and I definitely prefer not to rely on the outside world...

I had the same issue, and I have seen it fail with nixpkgs on other packages too, so I agree that it's definitely an upstream issue. For what it's worth,...

Would it make more sense to preserve either insertion order or `accepting` construction order?

Ah, I see, makes sense. It would probably make sense to wrap it in a `ComparableRekord`. Will think about it.