Several errors occur frequently into the logs of the oarapi service: This sounds like concurrency problems:
sqlalchemy.exc.InvalidRequestError: This session is in 'prepared' state; no further SQL can be emitted within this transaction
sqlalchemy.exc.PendingRollbackError: Can't reconnect until invalid transaction is rolled back. Please rollback() fully before proceeding (Background on this error at: https://sqlalche.me/e/20/8s2b)
Sep 16 13:34:47 kraken-cpu uvicorn[1900026]: [SQL: INSERT INTO frag_jobs (frag_id_job, frag_date, frag_state) VALUES (%(frag_id_job)s, %(frag_date)s, %(frag_state)s)]
Sep 16 13:34:47 kraken-cpu uvicorn[1900026]: [parameters: {'frag_id_job': 699893, 'frag_date': 1757947373, 'frag_state': 'LEON'}]
Sep 16 13:34:47 kraken-cpu uvicorn[1900026]: (Background on this error at: https://sqlalche.me/e/20/gkpj) (Background on this error at: https://sqlalche.me/e/20/7s2a)
Sep 16 13:34:47 kraken-cpu uvicorn[1900026]: [ WARNING] [2025-09-16 13:34:47,538] [oar.lib.job_handling::get_job:1470]: get_job(699948) raises exception: This Session's transaction has been rolled back due to a previous exception during flush. To begin a new transaction with this Session, first issue Session.rollback(). Original exception was: (raised as a result of Query-invoked autoflush; consider using a session.no_autoflush block if this flush is occurring prematurely)
Sep 16 13:34:47 kraken-cpu uvicorn[1900026]: (psycopg2.errors.UniqueViolation) duplicate key value violates unique constraint "frag_jobs_pkey"
Sep 16 13:34:47 kraken-cpu uvicorn[1900026]: DETAIL: Key (frag_id_job)=(699893) already exists.
Thje last one was looping and it only stopped when the oarapi service was restarted
Informations here: https://docs.sqlalchemy.org/en/20/errors.html#this-session-s-transaction-has-been-rolled-back-due-to-a-previous-exception-during-flush
and here: https://docs.sqlalchemy.org/en/20/errors.html#this-session-s-transaction-has-been-rolled-back-due-to-a-previous-exception-during-flush
Maybe a first aproach should be to check if the uvicorn can be configured as mono-tthreaded http service, with probably some performance drawbacks... this could validate the hypothesis of the API being non thread safe if no more errors occur.
Several errors occur frequently into the logs of the oarapi service: This sounds like concurrency problems:
Thje last one was looping and it only stopped when the
oarapiservice was restartedInformations here: https://docs.sqlalchemy.org/en/20/errors.html#this-session-s-transaction-has-been-rolled-back-due-to-a-previous-exception-during-flush
and here: https://docs.sqlalchemy.org/en/20/errors.html#this-session-s-transaction-has-been-rolled-back-due-to-a-previous-exception-during-flush
Maybe a first aproach should be to check if the uvicorn can be configured as mono-tthreaded http service, with probably some performance drawbacks... this could validate the hypothesis of the API being non thread safe if no more errors occur.