postgres issue LIMIT must not be negative

[sweet nacelle]

having issues with postgres

@grim sand

after setting to 10 ```est_id" ASC LIMIT -1 OFFSET 0
2026-02-06 13:11:00.752 CST [172] ERROR: LIMIT must not be negative
2026-02-06 13:11:00.752 CST [172] STATEMENT: SELECT DISTINCT "user"."id" AS "user_id", "user"."email" AS "user_email", "user"."plexUsername" AS "user_plexUsername", "user"."jellyfinUsername" AS "user_jellyfinUsername", "user"."username" AS "user_username", "user"."recoveryLinkExpirationDate" AS "user_recoveryLinkExpirationDate", "user"."userType" AS "user_userType", "user"."plexId" AS "user_plexId", "user"."jellyfinUserId" AS "user_jellyfinUserId", "user"."permissions" AS "user_permissions", "user"."avatar" AS "user_avatar", "user"."avatarETag" AS "user_avatarETag", "user"."avatarVersion" AS "user_avatarVersion", "user"."movieQuotaLimit" AS "user_movieQuotaLimit", "user"."movieQuotaDays" AS "user_movieQuotaDays", "user"."tvQuotaLimit" AS "user_tvQuotaLimit", "user"."tvQuotaDays" AS "user_tvQuotaDays", "user"."createdAt" AS "user_createdAt", "user"."updatedAt" AS "user_updatedAt" FROM "user" "user" ORDER BY "user"."id" ASC LIMIT -1 OFFSET 0

[grim sand]

send your logs

seerr logs

[sweet nacelle]

https://pastebin.com/LVMPmxgk

just a bunch of already exists from watchlist

[grim sand]

do you have seerr open anywhere (your users or you in a browser)

[sweet nacelle]

me in a browser rn

[grim sand]

close it

and monitor postgres

to see if it still spams

so it will help narrow down

[sweet nacelle]

still spams after closing my browser

after postgres restart it immediately spams as well

iirc wasnt this a issue on older postgres

[grim sand]

can you update to 18 or 17?

[sweet nacelle]

not easily lol but i can if u think thats whats needed

[grim sand]

will need to update to postgres 17 minimum. Could be that 16 is no longer supported by typeorm

[sweet nacelle]

ok i will and ill report back

[sweet nacelle]

same error with 17

hmm could these TVDB errors be causing it?

[grim sand]

doubt. chekck exact timestamps

2026-02-06 13:44:00.446

check 1:44 pm

seerr logs

[sweet nacelle]

this is it 026-02-06T13:44:00.005Z [debug][Jobs]: Starting scheduled job: Download Sync 2026-02-06T13:44:00.016Z [debug][Download Tracker]: Found 2 item(s) in progress on Sonarr server: sonarr

idk what else to check..... what would cause this LIMIT -1

[grim sand]

Now see if all the limit -1 timestamps if they align with thag download sync

[sweet nacelle]

i cant find any timestamps on the postgres logs. could this be the issue? its the only thing i see that is -1 in my settings json }, "dnsCache": { "enabled": true, "forceMinTtl": 0, "forceMaxTtl": -1 } }, "migrations": [ "0007_migrate_arr_tags" ] }

nothing stands out in my db anywhere ```seerr=# SELECT * FROM "setting" WHERE "name" LIKE '%limit%' OR "name" LIKE '%count%';
ERROR: relation "setting" does not exist
LINE 1: SELECT * FROM "setting" WHERE "name" LIKE '%limit%' OR "name...
^
seerr=# SELECT id FROM "season_request" WHERE "requestId" NOT IN (SELECT id FROM "media_request");
id

(0 rows)

seerr=# SELECT id FROM "media" WHERE "tmdbId" IS NULL;
id

(0 rows)

seerr=# SELECT id, username, "userType" FROM "user" WHERE "userType" IS NULL;
id | username | userType
----+----------+----------
(0 rows)

seerr=# \dt
List of relations
Schema | Name | Type | Owner
--------+------------------------+-------+----------
public | blacklist | table | blassley
public | discover_slider | table | blassley
public | issue | table | blassley
public | issue_comment | table | blassley
public | media | table | blassley
public | media_request | table | blassley
public | migrations | table | blassley
public | override_rule | table | blassley
public | season | table | blassley
public | season_request | table | blassley
public | session | table | blassley
public | user | table | blassley
public | user_push_subscription | table | blassley
public | user_settings | table | blassley
public | watchlist | table | blassley
(15 rows)

seerr=# ```

[grim sand]

Wdym you cant find timestamps

thats literally the timestamps

match that with your seerr logs

[grim sand]

the settings.json has nothing to do with this

[sweet nacelle]

most recent 2026-02-06 14:21:01.503 CST [373] ERROR: LIMIT must not be negative

here is seerr at that time

https://pastebin.com/VMFzVhzk

[grim sand]

to narrow it dow

go to settings > jobs & cache

wait

on settings.json

set them to

a cron timing thats like 24 hrs

while seerr is down

so if the limit issue still comes while these jobs dont occur

then it might be coming from watchlist sync

and could be why i cant recreate

i dont use watchlist

set

 "download-sync": {
   "schedule": "0 * * * * *"
  },
  "download-sync-reset": {
   "schedule": "0 0 1 * * *"
  },

to

 "download-sync": {
   "schedule": "0 0 3 * * *"
  },
  "download-sync-reset": {
   "schedule": "0 0 3 * * *"
  },

and start seerr

then monitor postgresql again

if limit comes

then

change watachlist sync too

to

 "plex-watchlist-sync": {
   "schedule": "0 0 3 * * *"
  },

so if that job never runs and the limit issue never occurs we will know for sure its watchlist sync

and we can fix

[sweet nacelle]

u want me to change them all now or change the 2 first and do a check

[grim sand]

change download sync and reset firsgt

so we can narrow down between them and watchlist

[sweet nacelle]

ok i changed them to 0 */12 * * *

0 */12 * * *

[grim sand]

yeah works

[sweet nacelle]

same error now im gonna try watchlist

same error with all 3 set high

[grim sand]

Are you accessing via reverse proxy or locally

Are you sure none of your users are connecter

Even when you restart, if they have browser open, it will load immediately

Or do you run something like homarr

Or gethomepage

• An uptime monitor (Uptime Kuma, Healthchecks, etc.)
• A browser tab that auto-reconnects
• A mobile app or widget in a dashboard app like Homarr or geethomepage
• A reverse proxy health check

These are the culprits I have in mind

If youre using nginx try

grep -E '/api/v1/(request|user)\?' /var/log/nginx/access.log | head -20

To see access logs too

[sweet nacelle]

no users are connected homarr was running with the widget i stopped homarr. and will check again

[sweet nacelle]

shutting down homarr seems to have stopped it with all three variables still set high in the settings.json

[grim sand]

So it was homarr

Let me check their code

[sweet nacelle]

possibly tho i do have all those tasks stopped with a high value now. should i try running them 1 by 1

[grim sand]

I dont think its the tasks

Bevaise it spammed even when we set it high

Until you stopped homarr

Very likely its homarr

Querying wrong

[sweet nacelle]

thats true. so homarr this whole time 🤦‍♂️

https://github.com/homarr-labs/homarr/blob/6dd13f6deac287e9aff67882f24c49ca4a7da813/packages/integrations/src/overseerr/overseerr-integration.ts#L44-L48

[sweet nacelle]

according to homarr dev its a me issue 🤷‍♂️

[grim sand]

Run this or wherever your postgres log is. Then on browser go to /request page or /user page.

tail -f /var/log/postgresql/postgresql-*.log | grep "LIMIT must not be negative

[sweet nacelle]

no errors "homarr" is still disabled

[grim sand]

@sweet nacelle one last test

Go to users page

But set the sort order to request count

That replicates exactly what homarr does

See if you see the error pop up

Also check with page size set to 100 too

[sweet nacelle]

nope no error either

homarr https://pastebin.com/9V4WNSTx

[grim sand]

Then not an issue with seerr

[grim sand]

We do not provide support for homarr

[sweet nacelle]

yeah all i know is the error is gone with homarr stopped. so clearly werre done here on seerr side

[unkempt basalt]

Sorry it's a usability problem on our side:
https://github.com/homarr-labs/homarr/pull/5001

We used limit -1 for some reason and as it worked for sqlite (where it then uses no limit), it was in our codebase until today. We now adjusted it so we request a reasonable amount. Did not make any sense in the first place to just request all pending requests / all users.

Small improvements that might make sense on your side are

• that you restrict the pageSize parameter to only positive values
• or that you handle -1 as take all

[grim sand]

Yeah I've already done that

Locally

Will be pushing later

Wanted to know the original root cause for the spam

So made @sweet nacelle go through all the debugging haha

Because it made no sense to me since seerr doesn't query that with -1 anywhere constantly. And they mentioned that it was spamming repeatedly so 😅

[grim sand]

On the db. Was curious if it was a server side job or frontend (which shouldn't because they said browser was closed)

[unkempt basalt]

Yeah makes sense, sorry 😅
At least we found it now

[grim sand]

No worries 😄

[unkempt basalt]

It was cronjob, with v1 we have background jobs that query the new data every few seconds to show live data. But it's not optimal as of now as it also sends requests if nobody is on the dashboard...

[grim sand]

Ah makes sense

I did dive into the homarr codebase to see where -1 was being used but I was doing it on github mobile and search showed nothing 🤣