[BUG]: While creating new items in a checklist app freezes and cannot load

[FonduemangVI]

Describe the bug

I have just recently setup jotty page. While adding new checklists and items to said checklists jotty page freezes and I get a timeout error.
I am running jotty with SSO and via a reverse proxy (SWAG) when the freeze occurs I can see what looks like a memory leak and heavy CPU usage.
Restarting or destroying the container does not help. As soon as it's started again I cannot load the page and I get a timeout and I can see the memory start climbing again.

Eventually the container hits approx 4gb RAM usage and then crashes

<--- Last few GCs --->
[1:0x72c08e885650] 782963 ms: Mark-Compact 4019.3 (4131.1) -> 4005.7 (4131.6) MB, 2129.03 / 0.85 ms (average mu = 0.145, current mu = 0.066) task; scavenge might not succeed
[1:0x72c08e885650] 785077 ms: Mark-Compact 4019.4 (4131.6) -> 4006.3 (4132.1) MB, 1971.82 / 0.77 ms (average mu = 0.107, current mu = 0.067) task; scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----
Container stopped
Container started

I cannot see anything that makes sense in the nginx logs

Steps to Reproduce

N/A

At this point I am not sure if the issue is the usage of the reverse proxy or not. However when initially creating a new instance of jotty page there is no issue to start with. This occurs after a bit of usage and the creation of a few lists

How do you run Jotty?

Docker

Jotty Version

1.18.0

Checklist

• I have searched across other issues to make sure this bug has not been already reported.

[fccview]

This is very interesting!

I (and many others) have been using Jotty for months with a reverse proxy and haven't gotten this behaviour.

Would you mind turning DEBUGGER=true and show me the container logs when things freeze that way?

I'm very curious to see what kind of redirects you are getting

Also maybe worth sharing your nginx settings and how you are proxying Jotty!

Sorry about this. Let's figure it out ♥️

[FonduemangVI]

Thanks for the response.

This is my nginx config using SWAG (https://github.com/linuxserver/docker-swag)
Additional info my DNS is provided by CloudFlare and I am proxying via them but that shouldn't be an issue I would have imagined

## Version 2026/01/20

server {
    listen 443 ssl;
#    listen 443 quic;
    listen [::]:443 ssl;
#    listen [::]:443 quic;

    server_name notes.domain.com;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth (requires ldap-location.conf in the location block)
    #include /config/nginx/ldap-server.conf;

    # enable for Authelia (requires authelia-location.conf in the location block)
    #include /config/nginx/authelia-server.conf;

    # enable for Authentik (requires authentik-location.conf in the location block)
    #include /config/nginx/authentik-server.conf;

    # enable for Tinyauth (requires tinyauth-location.conf in the location block)
    #include /config/nginx/tinyauth-server.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable for ldap auth (requires ldap-server.conf in the server block)
        #include /config/nginx/ldap-location.conf;

        # enable for Authelia (requires authelia-server.conf in the server block)
        #include /config/nginx/authelia-location.conf;

        # enable for Authentik (requires authentik-server.conf in the server block)
        #include /config/nginx/authentik-location.conf;

        # enable for Tinyauth (requires tinyauth-server.conf in the server block)
        #include /config/nginx/tinyauth-location.conf;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 192.168.30.43;
        set $upstream_port 1122;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
    }
}

And this is the container logs I am getting with debugger on

MIDDLEWARE - sessionId: Ntib_-_db-6pKRpuu-9Lpn_0tZFJIScDM3SSRLqRn-Y
MIDDLEWARE - cookies: [
  {
  name: 'cf_clearance',
  value: 'DCftu3m9_pbfZW0lo5WGmTvW0Ui3gM3g8avuQbDGNOM-1768968774-1.2.1.1-QRFWYV605N3fbVZGEXTFHBY8lrA8qxyqXSyYbiXvgPpsv2exjKBxOxjYzW2X4jDZ7mYIVYDgtn.TTnPJGTyS8emfpFfbDBFf80jRcj9gw886V0f6NRvDjaLI6MbUaIzvxNF_CCkV8WFXbKbDblEQ5EBmg5mseuWMO_GoCxYJ4VG13MSetGrxxV0oWCY7wuMEhkYPqOy0cc0jyAiWpYhe3O2LEAQW1K3HwoSyD3MfpQE'
},
  { name: 'sessionid', value: 'iaxscivjkfu635s0x4sq46jmoi545ub1' },
  {
  name: 'ph_phc_VOdeYnlevc2T63m3myFGjeBlRcIusRgmhfx6XL5a1iz_posthog',
  value: '{"$device_id":"019afe6c-d857-78e2-978e-c763b72417b1","distinct_id":"019afe6c-d857-78e2-978e-c763b72417b1"}'
},
  {
  name: 'authentik_proxy_8a128806',
  value: 'authentik_proxy_session_60d96d40-2a6b-46fd-aa86-d9059b935696'
},
  {
  name: 'session',
  value: 'Ntib_-_db-6pKRpuu-9Lpn_0tZFJIScDM3SSRLqRn-Y'
}
]
MIDDLEWARE - URL Resolution:
  INTERNAL_API_URL: (not set)
  APP_URL: https://notes.domain.com/
  request.nextUrl.origin: https://0.0.0.0:3000/
  → Using: https://notes.domain.com/
MIDDLEWARE - Session Check URL: https://notes.domain.com/api/auth/check-session
MIDDLEWARE - Session Check Response:
  status: 200
  statusText: OK
  ok: true

[FonduemangVI]

I've just noticed you've released a new version. I'll hold off on updating for now. Until we've figured this out.

[fccview]

Hey!
Yes, that was ready for a while and was fixing a few bugs I really wanted to get out of the way

Don't worry, I didn't forget about this issue, I just haven't gotten around to looking into it yet. It's hard to debug something that I can't replicate ♥️

[FonduemangVI]

No worries at all.

Just let me know what additional info or tests you need from me.

[fccview]

hey @FonduemangVI
before I change anything in the codebase, are you ok to try adding this env variable? INTERNAL_API_URL=http://localhost:3000

Restart your container and tell me if the issue persists?
If it does I'll see if there's any actual memory leak ❤️

[FonduemangVI]

I've added that env variable and no changes I can see.

Container logs

MIDDLEWARE - sessionId: Ntib_-_db-6pKRpuu-9Lpn_0tZFJIScDM3SSRLqRn-Y
MIDDLEWARE - cookies: [
  {
  name: 'cf_clearance',
  value: 'xeWDwPuaAc.GKpyRjkazJ.zxhKkacwdejfMMWGypHPU-1769060566-1.2.1.1-0JRE_Sxo.XivoqqyODABguCPcNXD4nFlcX.0_Q4H_noV70hH_cvBRzLNGUB1Oook73Yv3bv92hKvNc7Fl2xFxHs57zDUzdS1cM41SySA.aEzCjYp6mfUMPXJmZOg1CFTAKOFD9MTGZv6KxVOahUAkDPBVMhOPZvF086yVs_SjulCJI.XLyEf7rbicTCO1wtnVVjfXFUDiF8DhKttGbOMDHffefBmLO7DT81wlyJDuI4'
},
  {
  name: 'ph_phc_VOdeYnlevc2T63m3myFGjeBlRcIusRgmhfx6XL5a1iz_posthog',
  value: '{"$device_id":"019afe6c-d857-78e2-978e-c763b72417b1","distinct_id":"019afe6c-d857-78e2-978e-c763b72417b1"}'
},
  {
  name: 'session',
  value: 'Ntib_-_db-6pKRpuu-9Lpn_0tZFJIScDM3SSRLqRn-Y'
},
  {
  name: 'authentik_proxy_8a128806',
  value: 'authentik_proxy_session_e9a5cd22-2ef1-47f3-9656-f445c1605aed'
},
  { name: 'sessionid', value: 'da560xqbsnzgoovceiowlu4aps5m0dgm' },
  {
  name: 'messages',
  value: 'W1siX19qc29uX21lc3NhZ2UiLDAsMjUsIlN1Y2Nlc3NmdWxseSBzaWduZWQgaW4gYXMgTWljaGFlbC5UaG9tYXMuIiwiIl1d:1vince:D2UH2RAlDKyJ3Wd9WhMPk13tGN5HthkscU_M4S7J_Qs'
}
]
MIDDLEWARE - URL Resolution:
  INTERNAL_API_URL: http://localhost:3000
  APP_URL: https://notes.domain.com/
  request.nextUrl.origin: https://0.0.0.0:3000/
  → Using: http://localhost:3000
MIDDLEWARE - Session Check URL: http://localhost:3000/api/auth/check-session
MIDDLEWARE - Session Check Response:
  status: 200
  statusText: OK
  ok: true

Consumption of resources for example

Still the same behaviour

[fccview]

Hey, sorry, I just noticed your origin request is

https://0.0.0.0:3000

Would you mind using that for the internal api call? This is definitely a bug in Jotty, I'm just trying to pin point where it's coming from, as I can't replicate it for the life of me

[FonduemangVI]

Same behaviour with that set as well unfortunately

[fccview]

Ok, kinda going a bit mad with this one, I just can't replicate it 🤦
Sorry I need a bit more info,

• Can you access Jotty directly from localhost:, bypassing your swag proxy entirely? Does that still causes the issue or is it only happening when using your proxy setup?
• You showed me the FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory, is there also a JavaScript stack trace showing me what function was causing the memory leak?
• How many checklists/items do you have? Would you be able to provide the raw markdown of the one that's crashing? Unless it's just happening any time, at which point I'll fully exclude a data issue

the 0.0.0.0:3000 origin is definitely unusual and suggests next isn't receiving proper Host/X-Forwarded-Host headers from the proxy chain. That shouldn't cause a memory issue but it'd definitely create issues, is there any way you can set the headers manually to localhost:3000 and see if that improves the situation?

Sorry, kinda throwing shit at the wall to see what sticks at the moment, we can figure it out, but for now I don't have nearly as much info and this is a very isolated case, unless someone else shows up with the same issue and can provide me a pattern (which would be awesome as it'd help so much).

[FonduemangVI]

Hey so

It doesn't happen when not going via my reverse proxy. Which RP are you using? I can share my full config if needed?

This is all I'm seeing from the logs

[1:0x77a4af9c5650] 12126584 ms: Mark-Compact 4012.7 (4131.2) -> 3999.8 (4131.7) MB, 1446.50 / 0.75 ms  (average mu = 0.155, current mu = 0.086) task; scavenge might not succeed
[1:0x77a4af9c5650] 12128996 ms: Mark-Compact 4013.7 (4131.7) -> 4000.4 (4132.5) MB, 2270.44 / 0.66 ms  (average mu = 0.104, current mu = 0.059) task; scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

It's just happening anytime. Essentially I created a new install with no setup. Started setting up/using the app and created some checklists and then it just starts happening after an indeterminate amount of time and after happening I can no longer access the app via my RP

I'm doing some additional troubleshooting on my end with the RP config to see what I can do. Not sure if it's just a config option that SWAG has enabled by default or a NGINX thing

[fccview]

Having the full config and your docker-compose file would help so much!

I have tried with a simple nginx reverse proxy, a cloudflare tunnel for the custom URL and authentik for authentication, obviously without your exact setup I am just guessing.

The thing that confuses me the most is the lack of logs. The whole thing seems to be some sort of redirect loop but there's zero logs showing in your container/console and it's throwing me off quite a bit..

Btw not denying that there is an issue, I just have no idea where the issue could be