Thread

BA
Bouarguan Abdellah2:43 AMOpen in Slack
Hey everyone! 👋
My name is Abdellah Bouarguan. I've been diving into Archestra recently and find the project and what you're building incredibly interesting!
I would love to work on the UI state desync and concurrency vulnerability (Issue #4030).
---
About me
  • Computer Science engineering student at ENSA Tétouan
  • Massive Linux enthusiast (been using it since I was 9)
  • ~6 years of self-taught full-stack development (pre-AI era)
---
Proposed approach
I’m looking to tackle this issue not just for the bounty, but as a practical architecture assignment for my engineering program.
My current plan to fix the double-execution race condition is:
  • Implement a Postgres-backed distributed lock
- Using an "ON CONFLICT" write-lock
- Located in "chat-mcp-client.ts"
  • Add a state-cleansing step in "normalizeChatMessages.ts"
- Flip abandoned "approval-requested" states → "output-denied"
- Before DB persistence
---
Since the contributing docs highly recommend syncing with the core team first, I wanted to drop in and say hi!
Do you have any specific guides, architectural design choices, or feedback on this approach before I officially post my "/attempt" claim and spin up a PR?
Thanks!

3 replies
IK
Innokentii Konstantinov (archestra team)9:08 AMOpen in Slack
Hi, this one is already taken, sorry for that!
MK
Matvey Kukuy (archestra team)9:18 AMOpen in Slack
@user, the issue was assigned to another contributor 2 days ago. Please be respectful of the community and avoid interfering with other people's work.
💯1👍1
BA
Bouarguan Abdellah11:31 AMOpen in Slack
@user, @user, thank you for the clarification, and sorry if I seemed irrespectful.