we should probably log a warning too if this happens

Added a log entry

One question @akihikokuroda , is here where we need to check this? Because we are not using pk in the entire method 🤔

Thinking that in general, Django ORM should prevent this kind of things.

The issue is when the request is like this

https://qiskit-serverless-dev.quantum.ibm.com/api/v1/jobs/case+randomblob%281000000%29+when+not+null+then+1+else+1+end+/stop

It has a bad string in stead of the job id in the request url. It causes a database request with the string. The request that has the pk in the url always executes the get_queryset method before it calls the individual method.

I need to say that I am not being able to replicate it

I haven't tried it by myself. The issue says

The query time is controllable using parameter value [case randomblob(1000000) when not null then 1 else 1 end ], which caused the request to take [334] milliseconds, parameter value [case randomblob(10000000) when not null then 1 else 1 end ], which caused the request to take [2,141] milliseconds, when the original unmodified query with value [id] took [824] milliseconds.

Validating the id part should prevent this.

My doubt here is that it surprises me that django orm doesn't manage this and we have similar end-points that passed the tests so I'm trying to figure out if we are doing something that we should not do.

I've just tried to reproduce this issue but it didn't happen. So I can not see what happened. How about putting this fix in and see if the issue happens with it?

Before merge it let me try to pass another scan Monday with security to confirm it and solve any doubt, Aki.