search

fullstackhero / dotnet-starter-kit

Production Grade Cloud-Ready .NET 8 Starter Kit (Web API + Blazor Client) with Multitenancy Support, and Clean/Modular Architecture that saves roughly 200+ Development Hours! All Batteries Included.
https://fullstackhero.net/dotnet-webapi-boilerplate/
MIT License
5.19k stars 1.56k forks source link

Recurring Background Job with Multitenancy[BUG] #530

Closed 4m-world closed 4 months ago

4m-world commented 2 years ago

Describe the bug When you create a recurring job that does not require logged in user, and at the same time the job needs to interact with CRUD operation on the level of Tenant DB Context, it raises an exception as it does not recognize under which tenant the operation, as the context realis on the Tenant info from the logged-in user account.

274188A commented 2 years ago

possibly releated to this : https://github.com/fullstackhero/dotnet-webapi-boilerplate/pull/476

fretje commented 2 years ago

@274188A what you're referring to is a pr... this is an issue...

I think it's good keeping an issue around... as that pr can be superseded by another pr in the future (that current one is still a draft as well)...

Better to have discussions in an issue anyway I think...

Concerning the topic at hand... yes there is still an issue with running recurring jobs (see the mentioned PR). As recurring jobs are not executed in the context of a webrequest, so there is no current user nor a current tenant. These are arguments that will have to be set when actually scheduling the recurring job. When scheduling a recurring job, you can add any arguments to the method you're scheduling, so there you can supply tenantId for example.

The solution I propose in that pr goes a step further, namely to create a single entrypoint into hangfire where you can execute any mediatr IRequest. That mediater request (and its type) together with a tenantId and maybe a currentUser should then be arguments of that single entrypoint. I have it set up like that on an classic net framework project (see also the code I posted in the discussion of that pr), and it works very well.

I'll have to port that to this project eventually, but is lower priority right now than a lot of other things which I have to implement... so was hoping maybe someone could already go ahead with the things I posted ;-)

Zigimun commented 2 years ago

Like I mentonied in the PR I do not know how to integrate the Fretje solution, I would like to do it but dont know how :)

So any help by others is welcome :)

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

fretje commented 2 years ago

see also https://github.com/fullstackhero/dotnet-webapi-boilerplate/pull/572 ...

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

fretje commented 2 years ago

better put a label on this one... still needs fixin' ;-)

maxiar commented 1 year ago

Any News? Any workaround for recurring jobs with anónimous user & interact with DBcontext without tenant info error?

SaaidRajji commented 1 year ago

Hello, did you try to use dapper repo without the tenant Id?

maxiar commented 1 year ago

Hello, did you try to use dapper repo without the tenant Id?

I tried using the _repository.QueryAsync (without tenant param) and works fine but... the dapper repository is only for queries and read operation, doesn't expose writes operations, etc.. Some Recurring jobs need to save data in the DB... :(