-
Notifications
You must be signed in to change notification settings - Fork 44.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(backend): Ensure validity of OAuth credentials during graph execution #8191
feat(backend): Ensure validity of OAuth credentials during graph execution #8191
Conversation
✅ Deploy Preview for auto-gpt-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
- Move `KeyedMutex` to `autogpt_libs.utils.synchronize` - Add locks to transactions in `SupabaseIntegrationCredentialsStore`
This pull request has conflicts with the base branch, please resolve those so we can evaluate the pull request. |
…entials JIT Also: - Add exposed `acquire_credentials`, `release_credentials` methods to `AgentServer` - Add Pydantic model auto-deserialization support to `@expose` decorator - Make `ExecutionManager.agent_server_client` cached
…-are-fresh-before-using-them-in
Conflicts have been resolved! 🎉 A maintainer will review the pull request shortly. |
d48fbfe
to
fda2cf6
Compare
fda2cf6
to
5f3ef42
Compare
…-are-fresh-before-using-them-in
This pull request has conflicts with the base branch, please resolve those so we can evaluate the pull request. |
…-are-fresh-before-using-them-in
Conflicts have been resolved! 🎉 A maintainer will review the pull request shortly. |
…-are-fresh-before-using-them-in
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 |
@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, |
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:
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. |
…-are-fresh-before-using-them-in
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 |
Changes 🏗️
backend
@expose
decoratorbackend.executor
backend.server
IntegrationCredentialsManager
to handle and synchronize credentials-related operationsbackend.server.integrations
module withrouter
,creds_manager
, andutils
in itautogpt_libs
SupabaseIntegrationCredentialsStore
to ensure thread-safetyKeyedMutex
intoRedisKeyedMutex
and move toautogpt_libs.utils.synchronize