feat(backend): Ensure validity of OAuth credentials during graph execution

[Pwuts]

• Resolves #8179

Changes 🏗️

backend

• Added Pydantic model (de)serialization support to @expose decorator

backend.executor

• Change credential injection mechanism to acquire credentials just before execution
  • Also locks the credentials for the duration of the execution

backend.server

• Add IntegrationCredentialsManager to handle and synchronize credentials-related operations
• Make backend.server.integrations module with router, creds_manager, and utils in it

autogpt_libs

• Add mutexes to SupabaseIntegrationCredentialsStore to ensure thread-safety
• Move KeyedMutex to autogpt_libs.utils.synchronize

[netlify[bot]]

✅ Deploy Preview for auto-gpt-docs ready!

Name	Link
🔨 Latest commit	519e3966bf8ba3449f95636b26349d52c2d2f2e8
🔍 Latest deploy log	https://app.netlify.com/sites/auto-gpt-docs/deploys/670803c8d89969000804860f
😎 Deploy Preview	https://deploy-preview-8191--auto-gpt-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[github-actions[bot]]

This pull request has conflicts with the base branch, please resolve those so we can evaluate the pull request.

[github-actions[bot]]

Conflicts have been resolved! 🎉 A maintainer will review the pull request shortly.

[github-actions[bot]]

This pull request has conflicts with the base branch, please resolve those so we can evaluate the pull request.

[CLAassistant]

All committers have signed the CLA.

[github-actions[bot]]

Conflicts have been resolved! 🎉 A maintainer will review the pull request shortly.

[github-actions[bot]]

This pull request has conflicts with the base branch, please resolve those so we can evaluate the pull request.

[github-actions[bot]]

Conflicts have been resolved! 🎉 A maintainer will review the pull request shortly.

[ntindle]

Why are we locking the credential for the duration of the execution? Is it a write-only lock? Seems like we would basically be forcing one block using a credential at a time when blocks themselves can't modify the credentials.

I'm not convinced that this is desired behavior as I may want to update my credentials without stopping my agents

[Pwuts]

@ntindle because refreshing OAuth credentials causes the old tokens to become invalid. If we would allow refreshing tokens while they are in use, that would break the ongoing execution.

Also, IntegrationCredentialsManager.get(..) will refresh OAuth credentials as needed, so it isn't a read-only operation.

[ntindle]

my understanding of in-use is for the tiny time to pull the credential and send the request. the implementations definition is when a block that uses that credential is running

If I have five blocks that all use that same credential and I want to update it, when will it be updated? When the next block starts running? What if I have multiple agents using that credential? we could be basically locking a credential forever without the ability to update it

[Pwuts]

my understanding of in-use is for the tiny time to pull the credential and send the request. the implementations definition is when a block that uses that credential is running

If I have five blocks that all use that same credential and I want to update it, when will it be updated? When the next block starts running? What if I have multiple agents using that credential? we could be basically locking a credential forever without the ability to update it

Your concerns are valid, but I think they are addressed in the current implementation:

• Credentials are locked while in use, which is while a node that uses them is running. I am yet to see a case where this causes issues, e.g. a long-running block that needs credentials. The total running duration of the parent graph is not a factor.
  • Because getting credentials can result in a refresh (= invalidation + replacement) of the stored credentials, getting is an operation that potentially requires read/write access.
  • Checking whether a token has to be refreshed is subject to an additional refresh scoped lock to prevent unnecessary sequential refreshes when multiple executions try to access the same credentials simultaneously.
• We MUST lock credentials while in use to prevent them from being invalidated while they are in use, e.g. because they are being refreshed by a different part of the system.
• I implemented a two-tier locking mechanism in which updating gets priority over getting credentials. This is to prevent a long queue of waiting get requests from blocking essential credential refreshes or user-initiated updates.

It is possible to implement a reader/writer locking system where either multiple readers or a single writer can have simultaneous access, but this would add a lot of complexity to the mechanism. I'll look into it if the current ("simple") mechanism causes too much latency, which I don't expect.

[ntindle]

Note that when this merges, it was discussed to update this to use a more complex locking mechanism, but that was seen as unlikely to be needed for now and highly likely to significantly increase complexity. If we need to do that, we can later on