Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

uptime-kuma: Spliit return Internal Server Error 500 #221

Open
camrossi opened this issue Sep 18, 2024 · 3 comments
Open

uptime-kuma: Spliit return Internal Server Error 500 #221

camrossi opened this issue Sep 18, 2024 · 3 comments

Comments

@camrossi
Copy link

I am using uptime-kuma to monitor a few of my apps and spliit 1.9 always returns a 500 error.
This happens also if I use curl or wget against my spliit instance.

The logs of the spliit container contains this error:

Error: Cannot find module './undefined.json'
    at /usr/app/.next/server/chunks/2221.js:1:198
    at async /usr/app/.next/server/chunks/2221.js:1:19477
    at async /usr/app/.next/server/chunks/3166.js:148:9351
    at async /usr/app/.next/server/chunks/3166.js:148:9816
    at async /usr/app/.next/server/chunks/3166.js:148:10005
    at async X (/usr/app/.next/server/chunks/2221.js:1:17582) {
  code: 'MODULE_NOT_FOUND',
  digest: '1972969468'
}

This happens only with kuma/curl/wget but a browser works just fine so I guess there is something with the request headers perhaps.

Not really a big issue for now I accept 500 as a success

Thanks !

@CypressXt
Copy link

Hey,
I've noticed the same issue on my side as well.
You're right it can be fixed by adding the (apparently required) Accept-Language header:

Header in curl:

curl -v https://your.spliit.instance.tld -H 'Accept-Language: en-US'
[...]
< HTTP/2 200 
< server: nginx

Header in uptime-kuma:

{
    "Accept-Language": "en-US"
}

@ChristopherJohnston
Copy link
Contributor

probably due to the addition of i18n modules

dixneuf19 pushed a commit to dixneuf19/brassberry-gitops that referenced this issue Nov 10, 2024
See this probable root cause issue spliit-app/spliit#221

The bug was probably introduced with the following renovate upgrade
8a7ad96
@dixneuf19
Copy link

Hi,

Also impacted by this bug on my self hosted Kubernetes deployment. After an upgrade from 1.8.1 to 1.14.1 the pod started failing to be Running since the Startup/Readiness/Liveness Probe I set up on the / endpoint were failing because they did not use this header.

NAME                      READY   STATUS    RESTARTS      AGE
spliit-5648b49c6b-tdm77   0/1     Running   2 (87s ago)   11m  <-- never Ready since the probe fails
# ... old versions are OK

I had the same log as above

❯ kl spliit-5648b49c6b-tdm77 
Setting timezone to UTC...
Waiting 60s for database to be ready...
PostgreSQL database ready!
Prisma migrate and deploy...
Prisma schema loaded from prisma/schema.prisma
Datasource "db": PostgreSQL database "spliit", schema "public" at "spliit-postgresql:5432"

19 migrations found in prisma/migrations


No pending migrations to apply.

> [email protected] start
> next start

  ▲ Next.js 14.2.5
  - Local:        http://localhost:3000

 ✓ Starting...
 ✓ Ready in 1946ms
Error: Cannot find module './undefined.json'
    at /usr/app/.next/server/chunks/3215.js:1:443
    at async /usr/app/.next/server/chunks/3215.js:1:20983
    at async /usr/app/.next/server/chunks/9013.js:148:9245
    at async /usr/app/.next/server/chunks/9013.js:148:9710 {
  code: 'MODULE_NOT_FOUND',
  digest: '3224353063'
}
Error: Cannot find module './undefined.json'
...

I fixed it by adding this header to my probe (see fix)

          livenessProbe:
            httpGet:
              path: /
              port: http
              httpHeaders:
              - name: Accept-Language
                value: en-US
          readinessProbe:
            httpGet:
             path: /
             port: http
             httpHeaders:
             - name: Accept-Language
               value: en-US
          startupProbe:
            httpGet:
              path: /
              port: http
              httpHeaders:
              - name: Accept-Language
                value: en-US

I don't think this behavior is wanted, but maybe I should use another endpoint for healhtcheck.
I see two paths forward:

  • Either make this endpoint work without the Accept-Language header, perhaps by assuming a default value.
  • Or implement (or document if it exists, as I haven't found it) a specific programmatic health check endpoint on the server

Thanks for this great project!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants