You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
With the added support for dynamically adding tenants and spin up their agents (which is great 💯btw) we face an issue when we tear down a tenant at runtime.
All connected agents for said tenant will continue to run and try to poll something from the database.
But since the database was removed from the master table and after that, the database was dropped, it will result in
Npgsql.PostgresException (0x80004005): 3D000: database "xxx" does not exist
Exception data:
Severity: FATAL
SqlState: 3D000
MessageText: database "xxx" does not exist
File: postinit.c
Line: 945
Routine: InitPostgres
And lots of them :)
Describe the solution you'd like
It would be beneficial if the mechanism that determines the availability of a new tenant to initiate its agent could also identify when one of its active agents is no longer present in the master table and consequently terminate that tenant's agent.
Describe alternatives you've considered
If the above is rather complicated to implement, one other solution could be to detect the 3D000 error within the agent and stop it after a few retries.
Additional context
In our SaaS solution we dynamically provision tenants at runtime.
If a new tenant is created, we do
Create a new entry in the Master Table using Marten's Tenancy
Create the Postgres Database manually
Use Marten's DB Schema Migration functionality to create all DB objects
Seeds some system data using Marten
If a tenant is deleted, we do
Remove the entry from the Master Table using Marten's Tenancy
Drop the Postgres Database manually
Our solution consists of 4 different Wolverine powered applications.
Each application may have multiple replicas. They all work with the same Master database, but have their individual Schemas for Wolverine.
Tenants have their own Inbox/Outbox within their tenant database.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
With the added support for dynamically adding tenants and spin up their agents (which is great 💯btw) we face an issue when we tear down a tenant at runtime.
All connected agents for said tenant will continue to run and try to poll something from the database.
But since the database was removed from the master table and after that, the database was dropped, it will result in
And lots of them :)
Describe the solution you'd like
It would be beneficial if the mechanism that determines the availability of a new tenant to initiate its agent could also identify when one of its active agents is no longer present in the master table and consequently terminate that tenant's agent.
Describe alternatives you've considered
If the above is rather complicated to implement, one other solution could be to detect the 3D000 error within the agent and stop it after a few retries.
Additional context
In our SaaS solution we dynamically provision tenants at runtime.
If a new tenant is created, we do
If a tenant is deleted, we do
Our solution consists of 4 different Wolverine powered applications.
Each application may have multiple replicas. They all work with the same Master database, but have their individual Schemas for Wolverine.
Tenants have their own Inbox/Outbox within their tenant database.
The text was updated successfully, but these errors were encountered: