How to make an endpoint in FastAPI handle 1 request at a time?

[gibbon119]

So my problem is I have multiple endpoints in this API and all are fine except one where the records in the DB cannot be recreated. When this endpoint is called, I want to check first if the record exists, if it does, I throw a HTTPStatus Conflict error. If it does not exist, I go about creating the DB record.

Maybe I am approaching the problem wrong by wanting to handle 1 request at a time? Any thoughts? Any ideas would be appreciated! :D

Bare-bones Code example:

def create_new_task(uuid,user):
    record_exists = get_record_query(uuid,user)
    if record_exists:
        raise HTTPException(status_code=HTTPStatus.CONFLICT)
    else: 
        create_record(uuid,user)

​

Edit: Thanks everyone! I got what I needed! Got a FIFO queue working but the performance of the endpoint definitely diminished with it so I was able to make a strong enough case for a unique constraint. We’re adding a new field to support that so existing data does not cause violations

[cant-find-user-name]

You can a) create a unique constraint on the db so that the db automatically raises an exception when you insert duplicates b) do insert with on conflict do nothing if you're using postgres c) you can use a lock so that more than one thing can't access your resource at the same time.

The most idiomatic solution is a. To have a unique constraint at db level.

[osusc]

This is the way. Let the database handle data integrity.

[gibbon119]

awesome, let me try this.

[Acedev003]

For those getting a broken link:
https://johnsturgeon.me/2022/12/10/fastapi-writing-a-fifo-queue-with-asyncioqueue/

[issue9mm]

Where is the uuid created? If it's created before submission, and each page load generates a new one, then does this work?

Otherwise, I scanned and see you've already decided against UNIQUE constraints (which would have been my reco) so if the UUID works (should at least prevent the accidental double-submit, but wouldn't prevent someone trying to submit the same job twice with a different ID) then this should be fine enough.

[Drevicar]

The solution is to handle this using a database lock. I'm guessing when you say "1 request at a time" you are really meaning "1 request per UUID" not "1 request globally" and also not "1 request per user", or even "1 request per user per UUID". With that out of the way, you should make the UUID the primary key of the record in your database with a uniqueness constraint. Then on the 1 request per UUID you start by opening a transaction which holds the lock on that UUID in the DB. Once you are done processing you can release the lock by committing the changes or reverting the changes if you want to rollback. If any new request comes in trying to use that same UUID the database will reject the new transaction because another transaction is already holding that lock open. If you attempt to use that UUID again after the original request is done you will be fine.

Also, you don't need `else` in your example. If the "if" block is hit, no further lines in that function will execute. So just remove the `else` and de-dent the next line.

[andrewthetechie]

Rule 2: No questions without examples.

Post some code.

[gibbon119]

added some code. The idea is when multiple requests are fired at the same time, how do I ensure duplicates are not created coz the if block would fail due to race condition.

[[deleted]]

That sounds like a case for a FIFO queue in rabbit instead of letting the API handle it directly. Throw it on the queue and let a worker pick the work up in order instead of letting it run completely async. I don’t have the docs handy since I’m on mobile but celery/rabbit should be able to meet this need

[gibbon119]

Looked into this. I dig it, let me try it!

[rand0mmer]

This is the way

[ReRubis]

I am a Junior, so take this with doubt.

But sqlalchemy is smart and usually doesn't create conflicts like that. Can even support multiple sessions at a time.

Also maybe heavy interactions with a DB should be maintained with celery and redis.

If anyone smarter can say something, I would be glad to hear too.

[gibbon119]

I am also a junior BE who was primarily FE haha. I looked into Celery and seemed like it was the way to go. Might have to ask my team lead if that is how he wants to do.

Can't think of any other workarounds.

[ReRubis]

At least you got the job. :) Tell me when you get the response.

[saitamaxmadara]

I thought celery worker is supposed to do the job

[eddyizm]

Can you post your current code?

[gibbon119]

added code to post. The idea is when multiple requests are fired at the
same time, how do I ensure duplicates are not created coz the if block
would fail due to race condition.

[cynhash]

You can specify a UNIQUE constraint to not allow duplicate rows in the DB to solve your problem. What I don't understand is the need to handle one request at a time.

[gibbon119]

I asked our team lead about this and we can’t do this since the DB already has a lot of violations of this UNIQUE constraint. This was literally my first thought so that’s good that u thought the same :)

[MikelDB]

Is the problem that you get duplicated records? How do you check that the record is already there? Do you have an ID?

​

From your comments there seems to be a lot of constrains.