On the self-hosted instance, I see these errors appear quite often. What it is?

02 Aug 2023 18:30:18:397 +0000 | ERROR | pid: cbf1c137-e9a8-440c-899f-a3aa49318855 | [pool-1-thread-4] thread | io.supertokens.multitenancy.MultitenancyHelper.lambda$refreshTenantsInCoreBasedOnChangesInCoreConfigOrIfTenantListChanged$0(MultitenancyHelper.java:145) | Tenant(, public, public) | io.supertokens.pluginInterface.exceptions.StorageQueryException: org.postgresql.util.PSQLException: ERROR: prepared statement "S_5" already exists

And these:

02 Aug 2023 18:29:28:160 +0000 | ERROR | pid: cbf1c137-e9a8-440c-899f-a3aa49318855 | [http-nio-0.0.0.0-3567-exec-6] thread | io.supertokens.webserver.WebserverAPI.service(WebserverAPI.java:445) | Tenant(, public, public) | jakarta.servlet.ServletException: io.supertokens.pluginInterface.exceptions.StorageQueryException: org.postgresql.util.PSQLException: ERROR: bind message supplies 3 parameters, but prepared statement "S_7" requires 0

Also, I'm using https://neon.tech and I can see that supertoken always makes calls to the database or so, and that my computes are up as supertoken seems to ping it or try to do some queries or so. My app is before the release, so there are no clients and there are no calls to the database at all (I can see that by logs). So it's not my app that keeps computes alive. Is there a way to disable such pinging of the database? At least for the dev instance of supertoken that would be quite useful to save some money here.

hey @rip21

I use the latest one. And yeah I see about cron jobs. https://github.com/supertokens/supertokens-core/blob/master/src/main/java/io/supertokens/cronjobs/syncCoreConfigWithDb/SyncCoreConfigWithDb.java

> I can see that supertoken always makes calls to the database or so By default, supertokens keeps 10 connections to the db alive, and you can change this vlaue from the config.yaml (or docker env). But also, keeping those connections alive doesn't involve querying the db. If you are seeing queries to the db, its probably the cronjobs that are running in the core that are making those queries. Is ther a way to see those queries?

Any way to let it sync every 10 minutes or so? 🙂

unfortunately, not at the moment. We can add a config for it though.

It happnes when this is called

refreshTenantsInCoreBasedOnChangesInCoreConfigOrIfTenantListChanged

Thanks. We will investigate

I'll also try to replicate it locally. Also if you guys need I can create a connection string to branch on my neon instance, so you can check it.

@rip21 hey, I tried using neon db. I didn't see such a thing happening on my setup.

we couldn't connect to the connection uri you DMed me either

oh yea, there was a permission issue with the user -

Tenant(, public, public) | What caused the crash: io.supertokens.pluginInterface.exceptions.DbInitException: org.postgresql.util.PSQLException: ERROR: must be owner of table passwordless_codes

Yeah, I tried it myself, and it seems that somehow the first deployment was unlucky and it got into this weird state of constant retries and failures of some of the queries. Stopping the task completely, and letting it restart (without blue-green deployment, but full stop, and start again) fixed it. No errors in the logs. Although, making this CRON job interval that calls SyncCoreConfigWithDb, configurable, will be nice. I'm not entirely sure what it does, and why it should be called that often 🙂 BTW, is it also possible, to disable logging of

/hello

request, which is considered the default healthcheck? It just bloats the console so much. I usually reenable logging of health check routes for services only in case something goes wrong and I need to be 100% sure healthcheck is being called, which is rarely needed TBH.

You can set different log levels

And the last question for today,

Failed to validate connection org.postgresql.jdbc.PgConnection@5ba4e963 (This connection has been closed.). Possibly consider using a shorter maxLifetime value.

Anything I can do about it? I assume, making it so DB never sleeps will do the trick, but it defeats the purpose of serverless computes. These are warns BTW.

I think these can be ignored.

So far only annoyance I have is that DBs never fall asleep. But I'm unsure if they will fall asleep at all even if a job will be running every 10 minutes and not every minute, as JDBC and Hikari are probably doing some SELECT 1 when checking the connection or so making it stay alive. Quite annoying. Will consult with Neon about that and maybe drop you guys some ideas here on how to make it more compatible with serverless Postgres DBs. (Neon separates storage and computes, and since computes are more expensive than storage, sleeping computes when not in load is perfect as it makes some dev env or preview databse cost to be virtually around 10-20 cents a month. While production costs +- the same as permanently hosted DB (when the app is busy it almost never sleeps. Having supertokens always keeping it alive with all this pinging, makes that money saving feature useless basically)

I see. Fair enough. Im not sure if we can easily solve for this though. Some of the cronjobs are very important indeed.

Like, based on name SyncCoreConfigWithDb Is it really that often that config is getting changed?

Not really, but if you deploy multiple cores and the config changes, it is really important that the configs are synced quickly across the cores

Wondering if https://www.postgresql.org/docs/9.0/sql-notify.html cannot be used here to notify instances of changes. E.g. new instance starts - changes config The old instance gets the notification and updates immediately. Either way, if it's a dealbreaker for serverless DBs, I think that can be a special section in the docs, that will explain this nuance and what to do to disable this cron job and what are side effects and what to do in case the config change is actually expected.

oh yea, well, that's true. So it's not fully stateless. The configs are stored in memory after reading from the db, so we need to sync the memory with the db. However, as you said, config changes aren't frequent, so depending on your use case, it may not be an issue to make that cron run once an hour or even more infrequently. You can always fork the core and change that time value. We have instrs on building it from source.

I'll consider that 😛 Having source code is such a nice thing 😛 But I'm sure, in the future ppl will come asking the same question or so.

Sounds good. We shall look at it when we have time and it’s more of an urgency.

So, in the end, I opt out of hosting for dev and prod for the time being. I'll use the "hosted" version only in local development and for e2e testing.

Fair enough. So will you be using self hosted?

Nah, your cloud. As it's the most cost efficent for us for now. But self hosted for local development.