Closed laurenceisla closed 6 months ago
Hm, so the solution should be pinning a previous version of fuzzyset
?
Hm, so the solution should be pinning a previous version of fuzzyset?
At first glance, it should. But IIRC, previous versions have conflicts with the current GHC version. Particularly the base
and text
dependencies, I think (I may be wrong).
The evidence is that it is marked as "broken" in the latest update of nixpkgs/GHC in commit https://github.com/PostgREST/postgrest/commit/6682baebd21253ebb851d8c58548982736bc0714 (previous commits do not throw the error even with -K1K):
I don't think this is related. broken
just means it failed to build in nixpkgs at some point in the past. Nowadays it does build fine - thus I marked it unbroken in that PR.
But IIRC, previous versions have conflicts with the current GHC version.
Correct, we can't downgrade. But I don't see why we should here, I don't see a connection to fuzzyset
here, yet.
latest update of nixpkgs/GHC in commit https://github.com/PostgREST/postgrest/commit/6682baebd21253ebb851d8c58548982736bc0714 (previous commits do not throw the error even with -K1K):
Of course the only code changes in that are about fuzzyset
, so that might very well be an indication that this is related. It's just the broken
part that is certainly unrelated here. There is fuzzyset 0.3.2 available on hackage now, so maybe we first try updating the fuzzyset package to see whether that makes a difference.
The most likely explanation though is, that I just broke it with the code changes about fuzzyset that I made. So it might be worth reviewing them carefully.
It's just the broken part that is certainly unrelated here.
Ah, I thought of it as evidence that something happened there. But cool, it isn't related to a broken library, then.
There is fuzzyset 0.3.2 available on hackage now, so maybe we first try updating the fuzzyset package
The most likely explanation though is, that I just broke it with the code changes about fuzzyset that I made.
Cool, will do both to check what's happening.
Cool, will do both to check what's happening.
Tried to upgrade to 0.3.2
, but the problem persisted. Then, after checking the library's code, I used the most similar function to Fuzzy.getOne
, which is Fuzzy.closestMatch
, but the error was still there. I also mixed some code between the old/new library versions to no avail.
It may be that the library itself has the leaks, not really sure. Regardless, I think the best course of action is to downgrade to 0.2.4
, which is better than the version we had before because it's compatible with the other packages we have pinned in postgrest.cabal
.
Environment
Description of issue
When requesting a table that does not exist with any embedded resource, it shows a
stack overflow
error in the logs and fails the request. To reproduce:Expected:
This only happens in the Nix development environment for now (not for spec tests), since it enables the leak detection with
-K1K
:https://github.com/PostgREST/postgrest/blob/ec7ab271d69e8ad907328b34c7d1a4aed1c60af9/postgrest.cabal#L185
It appears that the
fuzzyset
package, used to build the "hint" of the error, is the culprit. The evidence is that it is marked as "broken" in the latest update of nixpkgs/GHC in commit 6682baeb (previous commits do not throw the error even with-K1K
):https://github.com/PostgREST/postgrest/blob/ec7ab271d69e8ad907328b34c7d1a4aed1c60af9/nix/overlays/haskell-packages.nix#L48-L49