Concurrent turns in the same session, still no official fix? (follow-up to #790)

[vietnamesekid]

Following up on #790 from last year. That one got a maintainer reply confirming this is a real gap:

"Yes, ADK does not support concurrent turns at the same time. We will put some enforcement in the session service, since the lock needs to be implemented at the server-side."

That was May 2025. Someone asked for an update in August 2025 and got nothing since. Figured a 1+ year old thread with no activity is easy to miss, so opening a new one with a concrete case attached.

Here's what we ran into. We have an ADK agent behind a Messenger webhook, DatabaseSessionService on Postgres, deployed on Cloud Run. Pretty normal setup. Problem is when a user sends two messages a few seconds apart (before the agent finishes replying to the first one), our webhook fires two separate POST /run calls for the same session at basically the same time. One of them loses.

On adk 1.24 to 1.27 the losing request just silently reloads and continues, so the second message gets dropped with zero error anywhere (this was issue #4751). On 1.28+ it at least raises a ValueError now instead of failing silently, which is better, but the message is still lost unless whoever's calling ADK bothers to retry.

Also worth noting, the asyncio.Lock inside DatabaseSessionService only works if both requests land on the same process. On Cloud Run you can easily get two instances handling the same user's messages, and that lock does nothing across instances. Only the DB-level locking actually catches it there, and even that just detects the conflict, it doesn't make one request wait for the other.

We ended up building basically what the OP of #790 already built back then, a lock keyed by session id sitting in front of ADK so two turns for the same session never run at the same time. Works fine but it feels like something that shouldn't have to live outside the framework, especially for anything chat-based where a user double-texting is just normal behavior, not an edge case.

Is this actually being worked on? Even just some docs saying "you need to serialize calls per session yourself, ADK won't do it for you" would save people from finding this out the hard way in production like we did.

Can share our DB traces of the dropped events if that's useful.