## Changes 🏗️
- Run the API query generation as part of the `dev` command
- update the `README` to reflect so
- Add CI job to generate queries and type-check to make sure we are not
out of sync
- the job is run both in Front-end and Back-end changes
- Generate the files via script to load the BE URL dynamically from the
env
- Remove generated files from Git
- rename the `type-check` command to `types`
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] CI passes
- [x] `README` updates make sense
#### For configuration changes:
None
---------
Co-authored-by: Zamil Majdy <zamil.majdy@agpt.co>
## Changes 🏗️
We had 2 flaky end-to-end tests:
- Build page → user can add two blocks and connect them
- this was failing sometimes because the `Run` button on the builder
does not work well, sometimes you need to click it twice for it to
work...
- Agent dashboard → edit actions
- some flaky tests asserting agent submissions not being there, pulled
the fixes from Abhi here on this PR
https://github.com/Significant-Gravitas/AutoGPT/pull/10545
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] E2E pass on the CI
- [x] Changes make sense
### For configuration changes:
None
## Changes 🏗️
Add the following caps to the **Agent Activity Dropdown**:
- display activity only from the last 72h
- display up to 1000 items
## Checklist 📋
### For code changes
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Open the agent activity with a big amount of times locally
- [x] It displays up to a 1000 and with 72h cap
### For configuration changes
None
Co-authored-by: Abhimanyu Yadav <122007096+Abhi1992002@users.noreply.github.com>
- Resolves#10444
Sometimes, the order of nodes and/or links isn't consistent between
frontend and backend, which currently can result in unnecessary
re-saving of the graph when the user tries to run it.
Also, `sub_graphs` was not included in the frontend `Graph` type, which
can cause unchecked code issues when the object is propragated using
spread operators.
### Changes 🏗️
- fix(frontend/builder): Make `graphsEquivalent` insensitive to link and
node order
- dx(frontend): Fix typing of `Graph.sub_graphs` (and its variants)
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- Import an agent and open it in the builder
- Run it without making any changes to the graph itself
- [x] -> graph shouldn't re-save
I’ve added a new launch darkly flag to toggle between the new and old
block menu in the builder.
### Changes 🏗️
- A new flag name `NEW_BLOCK_MENU` has been added.
- A new block menu block has been created, which is a normal component.
It will be expanded with more components in the future. Currently, it’s
just a one-line component.
- A new control panel has been created, which improves state
localisation and has a new design according to the design files.
<img width="1512" height="981" alt="Screenshot 2025-08-18 at 2 49 54 PM"
src="https://github.com/user-attachments/assets/3deeefe3-9e42-4178-9cf9-77773ed7e172"
/>
### Checklist 📋
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Everything works perfectly on local.
### Changes 🏗️
- Generate API client for orval v7.11.2
- Fix type error in `useAgentSelectStep.ts`
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Platform works
- [x] Updated codepath in `useAgentSelectStep.ts` works
## Summary
Fixes three critical issues in the admin dashboard spending page
(SECRT-1438):
- Fixed user search not working (P1) - query parameters weren't being
passed to backend
- Fixed broken pagination (P1) - server-side GET requests missing query
parameters
- Added visual feedback for credit updates (P3) - toast notifications,
loading states, auto-dismiss modal
## Root Cause
Server-side API requests weren't appending query parameters for
GET/DELETE requests in the `makeAuthenticatedRequest` function in
`helpers.ts`.
## Changes
- Added missing `transaction_filter` parameter to API client's
`getUsersHistory` method
- Fixed server-side GET request query parameter handling by updating
`makeAuthenticatedRequest` to use `buildUrlWithQuery`
- Added Suspense key to force re-render on URL parameter changes
- Added toast notifications for success/error states when adding credits
- Modal now closes automatically after successful submission
- Added loading state with disabled buttons during credit submission
- Page refreshes automatically to show updated balances
- Added debug logging to help diagnose parameter passing issues
## Test Plan
- [x] Search for users by email in admin spending dashboard
- [x] Navigate through pagination (Next/Previous buttons)
- [x] Filter by transaction type (Grant, Usage, etc.)
- [x] Add credits to a user account
- [x] Verify toast notification appears
- [x] Verify modal closes after successful submission
- [x] Verify balance updates without manual refresh
## Linear Issue
Closes [SECRT-1438](https://linear.app/autogpt/issue/SECRT-1438)
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Changes 🏗️
Update the Front-end `README` to clarify how to run the Front-end and
Back-end separately or together via Docker.
You can [preview the README
here](8f607ca852/autogpt_platform/frontend/README.md).
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] `README` makes sense and looks good formatting wise
### For configuration changes:
None
## Changes 🏗️
Not a helpful console log to land in production... We should disallow
console logs all together on the Front-end code, but that is a separate,
bigger PR...
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Go to the signup page
- [x] Play with the password inputs
- [x] Password is not printed in the console
#### For configuration changes:
None
<!-- Clearly explain the need for these changes: -->
We want to support ~~proxy curl~~ enrichlayer as an integration, and
this is a baseline way to get there
### Changes 🏗️
- Adds some subset of proxycurl blocks based on the API docs:
~~https://nubela.co/proxycurl/docs#people-api-person-profile-endpoint~~https://enrichlayer.com/docs/pc/#people-api
<!-- Concisely describe all of the changes made in this pull request:
-->
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
<!-- Put your test plan here: -->
- [x] manually test the blocks with an API key
- [x] make sure the automated tests pass
---------
Co-authored-by: SwiftyOS <craigswift13@gmail.com>
Co-authored-by: Claude <claude@users.noreply.github.com>
Co-authored-by: majdyz <zamil@agpt.co>
## Summary
This PR adds the frontend service to the Docker Compose configuration,
enabling `docker compose up` to run the complete stack, including the
frontend. It also implements comprehensive environment variable
improvements, unified .env file support, and fixes Docker networking
issues.
## Key Changes
### 🐳 Docker Compose Improvements
- **Added frontend service** to `docker-compose.yml` and
`docker-compose.platform.yml`
- **Production build**: Uses `pnpm build + serve` instead of dev server
for better stability and lower memory usage
- **Service dependencies**: Frontend now waits for backend services
(`rest_server`, `websocket_server`) to be ready
- **YAML anchors**: Implemented DRY configuration to avoid duplicating
environment values
### 📁 Unified .env File Support
- **Frontend .env loading**: Automatically loads `.env` file during
Docker build and runtime
- **Backend .env loading**: Optional `.env` file support with fallback
to sensible defaults in `settings.py`
- **Single source of truth**: All `NEXT_PUBLIC_*` and API keys can be
defined in respective `.env` files
- **Docker integration**: Updated `.dockerignore` to include `.env`
files in build context
- **Git tracking**: Frontend and backend `.env` files are now trackable
(removed from gitignore)
### 🔧 Environment Variable Architecture
- **Dual environment strategy**:
- Server-side code uses Docker service names
(`http://rest_server:8006/api`)
- Client-side code uses localhost URLs (`http://localhost:8006/api`)
- **Comprehensive config**: Added build args and runtime environment
variables
- **Network compatibility**: Fixes connection issues between frontend
and backend containers
- **Shared backend variables**: Common environment variables (service
hosts, auth settings) centralized using YAML anchors
### 🛠️ Code Improvements
- **Centralized env-config helper** (`/frontend/src/lib/env-config.ts`)
with server-side priority
- **Updated all frontend code** to use shared environment helpers
instead of direct `process.env` access
- **Consistent API**: All environment variable access now goes through
helper functions
- **Settings.py improvements**: Better defaults for CORS origins and
optional .env file loading
### 🔗 Files Changed
- `docker-compose.yml` & `docker-compose.platform.yml` - Added frontend
service and shared backend env vars
- `frontend/Dockerfile` - Simplified build process to use .env files
directly
- `backend/settings.py` - Optional .env loading and better defaults
- `frontend/src/lib/env-config.ts` - New centralized environment
configuration
- `.dockerignore` - Allow .env files in build context
- `.gitignore` - Updated to allow frontend/backend .env files
- Multiple frontend files - Updated to use env helpers
- Updates to both auto installer scripts to work with the latest setup!
## Benefits
- ✅ **Single command deployment**: `docker compose up` now runs
everything
- ✅ **Better reliability**: Production build reduces memory usage and
crashes
- ✅ **Network compatibility**: Proper container-to-container
communication
- ✅ **Maintainable config**: Centralized environment variable management
with .env files
- ✅ **Development friendly**: Works in both Docker and local development
- ✅ **API key management**: Easy configuration through .env files for
all services
- ✅ **No more manual env vars**: Frontend and backend automatically load
their respective .env files
## Testing
- ✅ Verified Docker service communication works correctly
- ✅ Frontend responds and serves content properly
- ✅ Environment variables are correctly resolved in both server and
client contexts
- ✅ No connection errors after implementing service dependencies
- ✅ .env file loading works correctly in both build and runtime phases
- ✅ Backend services work with and without .env files present
### Checklist 📋
#### For configuration changes:
- [x] `.env.default` is updated or already compatible with my changes
- [x] `docker-compose.yml` is updated or already compatible with my
changes
- [x] I have included a list of my configuration changes in the PR
description (under **Changes**)
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Lluis Agusti <hi@llu.lu>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Nicholas Tindle <nicholas.tindle@agpt.co>
Co-authored-by: Claude <claude@users.noreply.github.com>
Co-authored-by: Bentlybro <Github@bentlybro.com>
## Changes 🏗️
<img width="800" height="687" alt="Screenshot 2025-08-12 at 15 52 41"
src="https://github.com/user-attachments/assets/0d2d70b8-e727-428b-915e-d4c108ab7245"
/>
<img width="800" height="772" alt="Screenshot 2025-08-12 at 15 52 53"
src="https://github.com/user-attachments/assets/b9790616-3754-455e-b8f6-58cd7f6b5a18"
/>
Update the Account Settings ( `profile/settings` ) form so that:
- it uses the new Design System components
- it is split into 2 forms ( update email & notifications )
- the change password inputs have been removed instead we link to the
`/reset-password` page
- uses a normal API route and client query to update the email
This might fix as well an error we are seeing when updating email
preferences on dev. My guess is it is failing because previously it was
using a server action + supabase and it didn't have access to the
cookies auth 🍪
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Navigate to `/profile/settings`
- [x] Can update the email
- [x] Can change notification preferences
- [x] New E2E tests pass on the CI and make sense
### For configuration changes:
None
## Changes 🏗️
Use a skeleton for the martkeplace loading state, representing visually
how the place should looks. Looks a bit more stylish than the previous
`Loading...` text.
### Before
<img width="800" height="774" alt="Screenshot 2025-08-12 at 16 01 22"
src="https://github.com/user-attachments/assets/29e44a1a-2089-468c-a253-3a6b763ada5a"
/>
### After
<img width="800" height="761" alt="Screenshot 2025-08-12 at 16 01 01"
src="https://github.com/user-attachments/assets/5ad362ae-df1d-4a1b-90ae-9349a81a4d75"
/>
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Martketplace loading state looks good across screen sizes
### For configuration changes:
None
This PR has added end-to-end tests for the profile form page. These
tests include:
- Redirects to the login page when the user is not authenticated.
- Can save profile changes successfully.
- Can cancel profile changes (skipped because we need to fix the form
for this test).
### Changes 🏗️
- Added test-id's inside the ProfileInfoForm.
- Created a page object for the profile form page.
- Added a test for this page in `profile-form.spec.ts`.
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] All test are working perfectly locally
I have added e2e tests for agent dashboard page
It includes, tests like
- dashboard page loads successfully
- submit agent button works correctly
- agent table displays data correctly
- agent table actions work correctly
I’ve also updated the e2e test script to include some static agent
submissions, so I can test if it loads on the frontend.
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] All tests are working perfectly locally
<img width="469" height="177" alt="Screenshot 2025-08-08 at 12 13 42 PM"
src="https://github.com/user-attachments/assets/5e37afc3-c151-476a-84de-0a06f44a0722"
/>
Currently, we’re only seeing the top 20 agents, but we need to display
all of them until we see more call-to-action buttons.
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] All tests are working perfectly
- [x] It's working manually as well
Reverts Significant-Gravitas/AutoGPT#10536 to bring platform back up due
to this error:
```
│ Error creating Supabase client Error: @supabase/ssr: Your project's URL and API key are required to create a Supabase client! │
│ │
│ Check your Supabase project's API settings to find these values │
│ │
│ https://supabase.com/dashboard/project/_/settings/api │
│ at <unknown> (https://supabase.com/dashboard/project/_/settings/api) │
│ at bX (.next/server/chunks/3873.js:6:90688) │
│ at <unknown> (.next/server/chunks/150.js:6:13460) │
│ at n (.next/server/chunks/150.js:6:13419) │
│ at o (.next/server/chunks/150.js:6:14187) │
│ ⨯ Error: Your project's URL and Key are required to create a Supabase client! │
│ │
│ Check your Supabase project's API settings to find these values │
│ │
│ https://supabase.com/dashboard/project/_/settings/api │
│ at <unknown> (https://supabase.com/dashboard/project/_/settings/api) │
│ at bY (.next/server/chunks/3006.js:10:486) │
│ at g (.next/server/app/(platform)/auth/callback/route.js:1:5890) │
│ at async e (.next/server/chunks/9836.js:1:101814) │
│ at async k (.next/server/chunks/9836.js:1:15611) │
│ at async l (.next/server/chunks/9836.js:1:15817) { │
│ digest: '424987633' │
│ } │
│ Error creating Supabase client Error: @supabase/ssr: Your project's URL and API key are required to create a Supabase client! │
│ │
│ Check your Supabase project's API settings to find these values │
│ │
│ https://supabase.com/dashboard/project/_/settings/api │
│ at <unknown> (https://supabase.com/dashboard/project/_/settings/api) │
│ at bX (.next/server/chunks/3873.js:6:90688) │
│ at <unknown> (.next/server/chunks/150.js:6:13460) │
│ at n (.next/server/chunks/150.js:6:13419) │
│ at j (.next/server/chunks/150.js:6:7482) │
│ Error creating Supabase client Error: @supabase/ssr: Your project's URL and API key are required to create a Supabase client! │
│ │
│ Check your Supabase project's API settings to find these values │
│ │
│ https://supabase.com/dashboard/project/_/settings/api │
│ at <unknown> (https://supabase.com/dashboard/project/_/settings/api) │
│ at bX (.next/server/chunks/3873.js:6:90688) │
│ at <unknown> (.next/server/chunks/150.js:6:13460) │
│ at n (.next/server/chunks/150.js:6:13419) │
│ at h (.next/server/chunks/150.js:6:10561) │
│ Error creating Supabase client Error: @supabase/ssr: Your project's URL and API key are required to create a Supabase client! │
│ │
│ Check your Supabase project's API settings to find these values │
│ │
│ https://supabase.com/dashboard/project/_/settings/api │
│ at <unknown> (https://supabase.com/dashboard/project/_/settings/api) │
│ at bX (.next/server/chunks/3873.js:6:90688) │
│ at <unknown> (.next/server/chunks/150.js:6:13460) │
│ at n (.next/server/chunks/150.js:6:13419)
```
## Summary
This PR adds the frontend service to the Docker Compose configuration,
enabling `docker compose up` to run the complete stack including the
frontend. It also implements comprehensive environment variable
improvements and fixes Docker networking issues.
## Key Changes
### 🐳 Docker Compose Improvements
- **Added frontend service** to `docker-compose.yml` and
`docker-compose.platform.yml`
- **Production build**: Uses `pnpm build + serve` instead of dev server
for better stability and lower memory usage
- **Service dependencies**: Frontend now waits for backend services
(`rest_server`, `websocket_server`) to be ready
- **YAML anchors**: Implemented DRY configuration to avoid duplicating
environment values
### 🔧 Environment Variable Architecture
- **Dual environment strategy**:
- Server-side code uses Docker service names
(`http://rest_server:8006/api`)
- Client-side code uses localhost URLs (`http://localhost:8006/api`)
- **Comprehensive config**: Added build args and runtime environment
variables
- **Network compatibility**: Fixes connection issues between frontend
and backend containers
### 🛠️ Code Improvements
- **Centralized env-config helper** (`/frontend/src/lib/env-config.ts`)
with server-side priority
- **Updated all frontend code** to use shared environment helpers
instead of direct `process.env` access
- **Consistent API**: All environment variable access now goes through
helper functions
### 🔗 Files Changed
- `docker-compose.yml` & `docker-compose.platform.yml` - Added frontend
service
- `frontend/Dockerfile` - Added build args for environment variables
- `frontend/src/lib/env-config.ts` - New centralized environment
configuration
- Multiple frontend files - Updated to use env helpers
## Benefits
- ✅ **Single command deployment**: `docker compose up` now runs
everything
- ✅ **Better reliability**: Production build reduces memory usage and
crashes
- ✅ **Network compatibility**: Proper container-to-container
communication
- ✅ **Maintainable config**: Centralized environment variable management
- ✅ **Development friendly**: Works in both Docker and local development
## Testing
- ✅ Verified Docker service communication works correctly
- ✅ Frontend responds and serves content properly
- ✅ Environment variables are correctly resolved in both server and
client contexts
- ✅ No connection errors after implementing service dependencies
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
In this PR, I’ve added library page tests.
### Changes
I’ve added 9 tests: 8 for normal flows and 1 for checking edge cases.
Test names are something like:
- Library navigation is accessible from the navbar.
- The library page loads successfully.
- Agents are visible, and cards work correctly.
- Pagination works correctly.
- Sorting works correctly.
- Searching works correctly.
- Pagination while searching works correctly.
- Uploading an agent works correctly.
- Edge case: Search edge cases and error handling behave correctly.
Other than that, I’ve added a new utility that uses the build page to
help us create users at the start, which we could use to test the
library page.
- All tests are passing locally
<img width="514" height="465" alt="Screenshot 2025-07-12 at 11 13 41 AM"
src="https://github.com/user-attachments/assets/7a46c437-7db5-458b-b99a-4fa0d479866f"
/>
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] All library tests are working locally and on CI perfectly.
- Resolves#10553
### Changes 🏗️
- Remove frontend graph validation in `useAgentGraph:saveAndRun(..)`
- Remove now unused `ajv` dependency
- Implement graph validation error propagation (backend->frontend)
- Add `GraphValidationError` type in frontend and backend
- Add `GraphModel.validate_graph_get_errors(..)` method
- Fix error handling & propagation in frontend API request logic
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Saving & running a graph with missing required inputs gives a
node-specific error
- [x] Saving & running a graph with missing node credential inputs
succeeds with passed-in credentials
Updated login and signup pages to display the Turnstile CAPTCHA and
require verification only when running in a cloud environment. This
prevents unnecessary CAPTCHA prompts in local or non-cloud deployments.
### Changes 🏗️
Locally when you try to login with the wrong password, and you update
and login again, you get a warning about captcha which is wrong, so this
fix makes it so the captcha will only when running in a cloud
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
<!-- Put your test plan here: -->
- [x] Try to login with the wrong password, get "Invalid login
credentials" and try to login again, you should keep getting "Invalid
login credentials" and it should not mention captcha
This PR helps us bypass the proxy server in server-side requests,
allowing us to directly send requests to the backend and reduce latency.
### Changes 🏗️
- Introduced server-side detection to dynamically set the base URL for
API requests.
- Added error handling for server-side requests to log failures and
throw errors appropriately.
- Updated header management to include authentication tokens when
applicable.
### Checklist 📋
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] All E2E tests are working.
- [x] I have manually checked the server-side and client-side
components, and both are working perfectly.
- Resolves -
https://github.com/Significant-Gravitas/AutoGPT/issues/10433
- Depends on -
https://github.com/Significant-Gravitas/AutoGPT/pull/10427
- Need to review this pr, once this issue is fixed -
https://github.com/Significant-Gravitas/AutoGPT/issues/10404
I’ve created additional tests for the agents marketplace page
Tests that I have added
- Add to library button works and agent appears in library.
- Download button functionality works.
- Agent page details are visible.
- User can access agent page when logged in.
- User can access agent page when logged out
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] I have done all the tests and they are working perfectly
---------
Co-authored-by: Nicholas Tindle <nicholas.tindle@agpt.co>
Co-authored-by: Lluis Agusti <hi@llu.lu>
Co-authored-by: Zamil Majdy <zamil.majdy@agpt.co>
Co-authored-by: Ubbe <hi@ubbe.dev>
We currently use infinite scroll pagination in multiple places, but our
strategies vary across these locations. This repetitive code writing is
not ideal, and our current methods are also complex. We’re not utilising
React Query’s useInfiniteQuery hooks effectively.
To address these issues, we’re introducing a new component called
`InfiniteScroll` that handles pagination independently.
### How to use it?
- Use React Query’s `useInfiniteHook` to return multiple data points.
For pagination, we only need `fetchNextPage`, `hasNextPage`, and
`isFetchingNextPage`.
```ts
const {
data: agents,
fetchNextPage,
hasNextPage,
isFetchingNextPage,
isLoading: agentLoading,
} = useGetV2ListLibraryAgentsInfinite(
{
page: 1,
page_size: 8,
search_term: searchTerm || undefined,
sort_by: librarySort,
},
);
```
- Simply pass these three data points and the current data length to the
`InfiniteScroll` component. That's it
```tsx
<InfiniteScroll
dataLength={agents.length}
isFetchingNextPage={isFetchingNextPage}
fetchNextPage={fetchNextPage}
hasNextPage={hasNextPage}
loader={<LoadingSpinner />}
>
...
```
### Changes
- Add the `InfiniteScroll.tsx` component for consistency and simplicity
in pagination across the frontend.
- Update the current library page to use the `InfiniteScroll` component.
### Checklist 📋
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] I’ve tested everything locally, and it’s working perfectly fine.
- Resolves -
https://github.com/Significant-Gravitas/AutoGPT/issues/10428
- Depends on -
https://github.com/Significant-Gravitas/AutoGPT/pull/10427
- Need to review this pr, once this issue is fixed -
https://github.com/Significant-Gravitas/AutoGPT/issues/10404
I’ve created additional tests for the creators marketplace page
Tests that I have added
- User can access creator's page when logged out.
- User can access creator's page when logged in.
- Creator page details are visible.
- Agents in agent by sections navigation works.
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] I have done all the tests and they are working perfectly
With this PR, we’re changing the data fetching strategy on the
marketplace page. We’re now using autogenerated React queries.
### Changes
- Splits separate render logic and hook logic.
- Update the data fetching strategy.
- Currently, we’re seeing agents in the featured section and creators in
the featured creators section, even if they’re not set to “isFeatured”
true. I’ve fixed that also.
### Checklist 📋
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] All marketplace E2E tests are working.
- [x] I’ve tested all the links and checked if everything renders
perfectly on the marketplace page.
Make agent graph execution durable by making it retriable. When it fails
to retry, we should make the error visible to the UI.
<img width="900" height="495" alt="image"
src="https://github.com/user-attachments/assets/70e3e117-31e7-4704-8bdf-1802c6afc70b"
/>
<img width="900" height="407" alt="image"
src="https://github.com/user-attachments/assets/78ca6c28-6cc2-4aff-bfa9-9f94b7f89f77"
/>
### Changes 🏗️
* Make _on_graph_execution retriable
* Increase retry count for failing db-manager RPC
* Add test coverage for RPC failure retry
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
<!-- Put your test plan here: -->
- [x] Allow graph execution retry
## Summary
- Adds AI-generated activity status summaries for agent execution
results
- Provides users with conversational, non-technical summaries of what
their agents accomplished
- Includes comprehensive execution data analysis with honest failure
reporting
## Changes Made
- **Backend**: Added `ActivityStatusGenerator` module with async LLM
integration
- **Database**: Extended `GraphExecutionStats` and `Stats` models with
`activity_status` field
- **Frontend**: Added "Smart Agent Execution Summary" display with
disclaimer tooltip
- **Settings**: Added `execution_enable_ai_activity_status` toggle
(disabled by default)
- **Testing**: Comprehensive test suite with 12 test cases covering all
scenarios
## Key Features
- Collects execution data including graph structure, node relations,
errors, and I/O samples
- Generates user-friendly summaries from first-person perspective
- Honest reporting of failures and invalid inputs (no sugar-coating)
- Payload optimization for LLM context limits
- Full async implementation with proper error handling
## Test Plan
- [x] All existing tests pass
- [x] New comprehensive test suite covers success/failure scenarios
- [x] Feature toggle testing (enabled/disabled states)
- [x] Frontend integration displays correctly
- [x] Error handling and edge cases covered
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
- Resolves -
https://github.com/Significant-Gravitas/AutoGPT/issues/10426
- Need to review this pr, once this issue is fixed -
https://github.com/Significant-Gravitas/AutoGPT/issues/10404
I’ve created additional tests for the main page, divided into two parts:
one for basic functionality and the other for edge cases.
**Basic functionality:**
- Users can access the marketplace page when logged out.
- Users can access the marketplace page when logged in.
- Featured agents, top agents, and featured creators are visible.
- Users can navigate and interact with marketplace elements.
- The complete search flow works correctly.
**Edge cases:**
- Searching for a non-existent item shows no results.
### Changes
- Introduced a new test suite for the marketplace, covering basic
functionality and edge cases.
- Implemented the MarketplacePage class to encapsulate interactions with
the marketplace page.
- Added utility functions for assertions, including visibility checks
and URL matching.
- Enhanced the LoginPage class with a goto method for navigation.
- Established a comprehensive search flow test to validate search
functionality.
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] I have done all the tests and they are working perfectly
---------
Co-authored-by: Nicholas Tindle <nicholas.tindle@agpt.co>
Co-authored-by: Lluis Agusti <hi@llu.lu>
Co-authored-by: Zamil Majdy <zamil.majdy@agpt.co>
Co-authored-by: Ubbe <hi@ubbe.dev>
## Changes 🏗️
- Moved API call from `usePublishAgentModal` to `useAgentInfoStep` for
better encapsulation
- overall cleaner state management + [state
colocation](https://kentcdodds.com/blog/state-colocation-will-make-your-react-app-faster)
- Added loading states with a spinner to the submit button during API
call
- Removed redundant validation: now relies entirely on zod schema
validation
- All thumbnails now use 16:9 (`aspect-video`) aspect ratio for
consistency
- Highlight selected thumbnails with blue border
- Table alignment fixes
- Rename `Edit` action to `View` to better reflect the content of the
modal that appears when clicked...
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] API calls work with loading states in Agent Info Step
- [x] Image aspect ratios are consistent across all components
- [x] Form validation works through zod schema only
### For configuration changes:
None
## Changes 🏗️
### Why these changes
We have a high-priority bug where the publish agent modal wouldn't open
when clicking `Edit` on the Dashboard Creator page table. The create
form was also buggy.
When looking into the code, I noticed it was pretty messy. I went ahead
and refactored it:
- [x] separation of concerns ( _split render / hook logic_ )
- [x] split into sub-components ( `PublishAgentModal/components` )
- [x] colocated state ( moved state to the modal steps rather than
having everything top-level )
- [x] used the new Design System components
Overall, we end up with a cleaner and stable experience ✨
### E2E tests
I also added E2E tests 🤖 to make sure we catch regressions in the future
in this modal. For now, it tests the first 2 steps. It does not do image
upload and publish as that wasn't working locally ( _might iterate on
that later_ )
### Step 1 – Select Agent
<img width="1161" height="859" alt="Screenshot 2025-07-29 at 16 12 46"
src="https://github.com/user-attachments/assets/a4949fb0-1a44-4926-a374-51eefadef063"
/>
### Step 2 – Agent Info Form
<img width="1061" height="804" alt="Screenshot 2025-07-29 at 16 03 11"
src="https://github.com/user-attachments/assets/b9a45bda-18ea-4844-b52c-db499f45193e"
/>
### Step 3 – Agent Review
<img width="1480" height="867" alt="Screenshot 2025-07-29 at 16 11 07"
src="https://github.com/user-attachments/assets/248bdf58-886d-43f3-a37a-35fd1a83e566"
/>
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] open the modal through the Account menu → ( `Publish Agent` )
- [x] complete the form and check validation errors
- [x] add images and generate image
- [x] publish the agent
- [x] the agent shows up on the table
- [x] Open an agent under review in the table ( _click `Edit` on the
actions_ )
- [x] it opens the modal on the 3rd step ( _review step_ )
### For configuration changes:
None
---------
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
Co-authored-by: Abhimanyu Yadav <122007096+Abhi1992002@users.noreply.github.com>
## Changes 🏗️
My previous PR,
https://github.com/Significant-Gravitas/AutoGPT/pull/10480, didn't fully
resolve the issue of broken links sometimes appearing for some runs in
the Agent Activity dropdown.
- Fixed the logic ( verified with a deployment in dev... )
- Simplified logic, making less API calls
- If we have an execution without a clear agent ID, we display it but
don't link to it
- Re-generated API types ( _had to update call in dashboard agents
because of it_ )
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Run agents
- [x] Runs appear correctly in the activity dropdown without broken
links
### For configuration changes:
None
## Changes 🏗️
Fix the issue where sometimes the agent activity would show a link to
agent runs that are not available in the library. So only show runs that
can be verified in the library. Improve the display of the agent name as
well 🤔
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Run agents
- [x] There are no empty links on the activity dropdown
- [x] Agent names look good 💅🏽
### For configuration changes:
None
## Changes 🏗️
There is a bug where the agent activity dropdown bubble only shows up to
`6` even if there are `50 running agents`. We only display the last 6
runs in the dropdown, but the bubble badge count should show the correct
all running agents.
On top of that we added the option to search runs by agent name when you
have more than 6 recent runs:
https://github.com/user-attachments/assets/931e3db7-5715-48d1-b4df-22490fae9de0
- Also make the dropdown items a link ( `a` ) so that you can command
click them to open runs in new tabs.
- Keep up to `400` executions on the state ( worse case load test )
- Each execution object is relatively small (ID, status, timestamps,
agent info)
- 400 objects × ~`1KB` each = negligible memory footprint `400kb`
- Always display running agents at the top
- Only display runs from the last week on the dropdown
- the agent library page contains the historical runs, this is just to
show the recent ones
### Code changes
- **Added count tracking**
- the `NotificationState` interface now includes separate count fields
(`activeCount`, `recentCompletionsCount`, `recentFailuresCount`) to
track the actual numbers independent of display limits.
- **Dual array system:**
- the `categorizeExecutions` function now creates:
- unlimited arrays for counting all executions
- limited arrays (sliced to 6 items) for dropdown display
- Updated all helper functions to properly maintain both the display
arrays and the count fields.
- Component uses actual counts
- `<AgentActivityDropdown />` component now uses `activeCount` for the
badge and hover hint instead of `activeExecutions.length`
## Checklist 📋
### For code changes
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Login and navigate to library or build
- [x] Start running agents like there is no tomorrow
- [x] The badge shows the correct agent execution count ( .i.e 10 )
- [x] The dropdown only displays the 6 most recent
- [x] You can command click on the runs and they open in new tabs
### For configuration changes
None
We want scrolling for agent dialog list
- Based on #9833
### Changes 🏗️
- adds backend support for paginating this content
- adds frontend support for scrolling pagination
<!-- Concisely describe all of the changes made in this pull request:
-->
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
<!-- Put your test plan here: -->
- [x] test UI for this
---------
Co-authored-by: Venkat Sai Kedari Nath Gandham <154089422+Kedarinath1502@users.noreply.github.com>
Co-authored-by: Claude <claude@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
- Resolves#10458
### Changes 🏗️
Improve logic in `useAgentGraph`:
- Correctly handle unset `flowVersion` in checks in hooks
- Prevent unnecessary WebSocket re-connects
- Remove redundant WebSocket connection management logic
- Untangle hooks for initial load and set-up
- Simplify block filtering logic
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- Edit an agent in the builder
- [x] WebSocket doesn't re-connect unnecessarily
- [x] Graph doesn't reset on WebSocket re-connect
- [x] Graph doesn't reset on LaunchDarkly re-connect
## Changes 🏗️
- Close websocket connections gracefully during logout ( _whether from
another tab or not_ )
- Also fixed an error on `HeroSection` that shows when the onboarding is
disabled locally ( `null` )
- Uncomment legit tests about connecting/saving agents
- Centralise local storage usage through a single service with typed
keys
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Login in 3 tabs ( 1 builder, 1 marketplace, 1 agent run view )
- [x] Logout from the marketplace tab
- [x] The other tabs show logout state gracefully without toasts or
errors
- [x] Websocket connections are closed ( _devtools console shows that_ )
### For configuration changes:
None
This PR implements a comprehensive Ayrshare social media integration for
AutoGPT Platform, enabling users to post content across multiple social
media platforms through a unified interface. Ayrshare provides a single
API to manage posts across Facebook, Twitter/X, LinkedIn, Instagram,
YouTube, TikTok, Pinterest, Reddit, Telegram, Google My Business,
Bluesky, Snapchat, and Threads.
The integration addresses the need for social media automation and
content distribution workflows within AutoGPT agents, allowing users to:
- Connect their social media accounts via SSO
- Post content with platform-specific options and constraints
- Schedule posts across multiple platforms simultaneously
- Handle platform-specific media requirements and validation
⚠️ To simplify the review process all except the twitter post block has
been commented out, future pr's will uncomment other platfroms so we can
test them in isolation.
### Changes 🏗️
#### Backend Integration (`backend/integrations/ayrshare.py`)
- **AyrshareClient**: Complete API client implementation with post
creation, profile management, and JWT generation
- **SocialPlatform enum**: Comprehensive platform definitions for all
supported social networks
- **Response models**: PostResponse, ProfileResponse, JWTResponse for
type-safe API interactions
- **Error handling**: Custom AyrshareAPIException with proper HTTP
status code handling
#### Social Media Posting Blocks (`backend/blocks/ayrshare/post.py`)
- **BaseAyrshareInput**: Shared input schema with common fields (post
text, media URLs, scheduling, etc.)
- **Platform-specific blocks**: 13 dedicated posting blocks, each with
platform-specific validation and options:
- PostToFacebookBlock: Carousel, Reels, Stories, targeting, alt text
- PostToXBlock: Threads, polls, long posts, premium features, subtitles
- PostToLinkedInBlock: Document support, visibility controls, audience
targeting
- PostToInstagramBlock: Stories, Reels, user tags, collaborators
- PostToYouTubeBlock: Video uploads, playlists, visibility, country
targeting
- PostToPinterestBlock: Pins, carousels, board management
- PostToTikTokBlock: Video/image posts, AI labeling, brand content
- PostToRedditBlock: Basic posting functionality
- PostToTelegramBlock: GIF handling, mentions
- PostToGMBBlock: Event/offer posts, call-to-action buttons
- PostToBlueskyBlock: Character limit validation, alt text
- PostToSnapchatBlock: Story types, video thumbnails
- PostToThreadsBlock: Hashtag restrictions, carousel support
#### Helper Models
- **CarouselItem**: Facebook carousel configuration
- **CallToAction, EventDetails, OfferDetails**: Google My Business post
types
- **InstagramUserTag**: Instagram user tagging with coordinates
- **LinkedInTargeting**: LinkedIn audience targeting options
- **PinterestCarouselOption**: Pinterest carousel image options
- **YouTubeTargeting**: YouTube country blocking/allowing
#### Authentication & SSO (`backend/server/integrations/router.py`)
- **SSO endpoint**: `/integrations/ayrshare/sso_url` for account linking
- **Profile management**: Automatic profile creation and key management
- **JWT generation**: Secure token generation for social media account
linking
- **Platform allowlist**: Configured access to all supported social
platforms
#### Frontend Integration (`frontend/src/components/CustomNode.tsx`)
- **AYRSHARE block type**: New BlockUIType.AYRSHARE for
Ayrshare-specific nodes
- **SSO button**: "Connect Social Media Accounts" with loading states
- **Handle generation**: Special handling for Ayrshare blocks with SSO
integration
#### Configuration
- **Environment variables**: Added AYRSHARE_API_KEY and AYRSHARE_JWT_KEY
to .env.example
- **Block registration**: All Ayrshare blocks registered in
AYRSHARE_NODE_IDS array
#### Type Safety & Error Handling
- **Modern typing**: Updated to use `list`, `dict`, `Any` instead of
legacy typing
- **Comprehensive validation**: Platform-specific constraints (character
limits, media counts, file types)
- **User-friendly errors**: Clear error messages for validation failures
and API errors
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
**Test Plan:**
**Backend API Testing:**
- [x] Verify AyrshareClient initializes correctly with API key
- [x] Test JWT generation for SSO authentication
- [x] Test profile creation and management
- [x] Verify all 13 posting blocks are properly registered
- [x] Test platform-specific validation rules for each block
- [x] Verify error handling for missing credentials and API failures
**Frontend Integration Testing:**
- [x] Verify AYRSHARE block type renders correctly in flow editor
- [x] Test SSO button functionality and popup window behavior
- [x] Confirm loading states work properly during authentication
- [x] Verify input handles generate correctly for Ayrshare blocks
- [x] Test platform-specific input fields and validation
**End-to-End Workflow Testing:**
- [x] Create agent with Ayrshare posting blocks
- [x] Test SSO flow: click "Connect Social Media Accounts" button
- [x] Verify popup opens with Ayrshare authentication page
- [x] Test social media account linking process
- [x] Create posts with various platform-specific options:
- [ X ] X (Twitter) - tested basic posting with image
- [] Test scheduling functionality across platforms
- [x] Verify media upload constraints and validation
- [] Test error handling for invalid inputs and failed posts
**Error Case Testing:**
- [] Test behavior with missing AYRSHARE_API_KEY configuration
- [] Test invalid social media credentials handling
- [] Test network failure scenarios
- [] Verify platform-specific validation error messages
- [] Test character limit enforcement per platform
- [] Test media file type and size restrictions
**Security Testing:**
- [ x ] Verify JWT tokens are properly generated and validated
- [x] Test profile key isolation between users
- [x] Confirm sensitive credentials are not logged
- [x] Verify SSO popup prevents XSS attacks
#### For configuration changes:
- [x] `.env.example` is updated or already compatible with my changes
- [x] `docker-compose.yml` is updated or already compatible with my
changes
- [x] I have included a list of my configuration changes in the PR
description (under **Changes**)
**Configuration Changes:**
- Added `AYRSHARE_API_KEY` environment variable for Ayrshare API
authentication
- Added `AYRSHARE_JWT_KEY` environment variable for SSO token generation
- No docker-compose.yml changes required (uses existing backend
services)
---------
Co-authored-by: Reinier van der Leer <pwuts@agpt.co>
## Overview
This PR adds comprehensive Airtable integration to the AutoGPT platform,
enabling users to seamlessly connect their Airtable bases with AutoGPT
workflows for powerful no-code automation capabilities.
## Why Airtable Integration?
Airtable is one of the most popular no-code databases used by teams for
project management, CRMs, inventory tracking, and countless other use
cases. This integration brings significant value:
- **Data Automation**: Automate data entry, updates, and synchronization
between Airtable and other services
- **Workflow Triggers**: React to changes in Airtable bases with
webhook-based triggers
- **Schema Management**: Programmatically create and manage Airtable
table structures
- **Bulk Operations**: Efficiently process large amounts of data with
batch create/update/delete operations
## Key Features
### 🔌 Webhook Trigger
- **AirtableWebhookTriggerBlock**: Listens for changes in Airtable bases
and triggers workflows
- Supports filtering by table, view, and specific fields
- Includes webhook signature validation for security
### 📊 Record Operations
- **AirtableCreateRecordsBlock**: Create single or multiple records (up
to 10 at once)
- **AirtableUpdateRecordsBlock**: Update existing records with upsert
support
- **AirtableDeleteRecordsBlock**: Delete single or multiple records
- **AirtableGetRecordBlock**: Retrieve specific record details
- **AirtableListRecordsBlock**: Query records with filtering, sorting,
and pagination
### 🏗️ Schema Management
- **AirtableCreateTableBlock**: Create new tables with custom field
definitions
- **AirtableUpdateTableBlock**: Modify table properties
- **AirtableAddFieldBlock**: Add new fields to existing tables
- **AirtableUpdateFieldBlock**: Update field properties
## Technical Implementation Details
### Authentication
- Supports both API Key and OAuth authentication methods
- OAuth implementation includes proper token refresh handling
- Credentials are securely managed through the platform's credential
system
### Webhook Security
- Added `credentials` parameter to WebhooksManager interface for proper
signature validation
- HMAC-SHA256 signature verification ensures webhook authenticity
- Webhook cursor tracking prevents duplicate event processing
### API Integration
- Comprehensive API client (`_api.py`) with full type safety
- Proper error handling and response validation
- Support for all Airtable field types and operations
## Changes 🏗️
### Added Blocks:
- AirtableWebhookTriggerBlock
- AirtableCreateRecordsBlock
- AirtableDeleteRecordsBlock
- AirtableGetRecordBlock
- AirtableListRecordsBlock
- AirtableUpdateRecordsBlock
- AirtableAddFieldBlock
- AirtableCreateTableBlock
- AirtableUpdateFieldBlock
- AirtableUpdateTableBlock
### Modified Files:
- Updated WebhooksManager interface to support credential-based
validation
- Modified all webhook handlers to support the new interface
## Test Plan 📋
### Manual Testing Performed:
1. **Authentication Testing**
- ✅ Verified API key authentication works correctly
- ✅ Tested OAuth flow including token refresh
- ✅ Confirmed credentials are properly encrypted and stored
2. **Webhook Testing**
- ✅ Created webhook subscriptions for different table events
- ✅ Verified signature validation prevents unauthorized requests
- ✅ Tested cursor tracking to ensure no duplicate events
- ✅ Confirmed webhook cleanup on block deletion
3. **Record Operations Testing**
- ✅ Created single and batch records with various field types
- ✅ Updated records with and without upsert functionality
- ✅ Listed records with filtering, sorting, and pagination
- ✅ Deleted single and multiple records
- ✅ Retrieved individual record details
4. **Schema Management Testing**
- ✅ Created tables with multiple field types
- ✅ Added fields to existing tables
- ✅ Updated table and field properties
- ✅ Verified proper error handling for invalid field types
5. **Error Handling Testing**
- ✅ Tested with invalid credentials
- ✅ Verified proper error messages for API limits
- ✅ Confirmed graceful handling of network errors
### Security Considerations 🔒
1. **API Key Management**
- API keys are stored encrypted in the credential system
- Keys are never logged or exposed in error messages
- Credentials are passed securely through the execution context
2. **Webhook Security**
- HMAC-SHA256 signature validation on all incoming webhooks
- Webhook URLs use secure ingress endpoints
- Proper cleanup of webhooks when blocks are deleted
3. **OAuth Security**
- OAuth tokens are securely stored and refreshed
- Scopes are limited to necessary permissions
- Token refresh happens automatically before expiration
## Configuration Requirements
No additional environment variables or configuration changes are
required. The integration uses the existing credential management
system.
## Checklist 📋
#### For code changes:
- [x] I have read the [contributing
instructions](https://github.com/Significant-Gravitas/AutoGPT/blob/master/.github/CONTRIBUTING.md)
- [x] Confirmed that `make lint` passes
- [x] Confirmed that `make test` passes
- [x] Updated documentation where needed
- [x] Added/updated tests for new functionality
- [x] Manually tested all blocks with real Airtable bases
- [x] Verified backwards compatibility of webhook interface changes
#### Security:
- [x] No hard-coded secrets or sensitive information
- [x] Proper input validation on all user inputs
- [x] Secure credential handling throughout
<!-- Clearly explain the need for these changes: -->
### Changes 🏗️
<!-- Concisely describe all of the changes made in this pull request:
-->
This PR contains code changes that will resolve the cursor jump issue in
the **Note** block #9252 . The changes in code affects the
NodeTextBoxInput component to transfer the state into local state and
not mutate the `value` prop directly.
Also includes change to use store admin which is from rebase issue but
approved by maintainer @ntindle
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Tested the note block allows to edit text normally
https://github.com/user-attachments/assets/f2800bf1-9867-4627-ac9d-44718627b263
---------
Co-authored-by: Nicholas Tindle <nicholas.tindle@agpt.co>
Co-authored-by: Abhimanyu Yadav <122007096+Abhi1992002@users.noreply.github.com>
Co-authored-by: Zamil Majdy <zamil.majdy@agpt.co>
Co-authored-by: Ubbe <hi@ubbe.dev>
## Changes 🏗️
Fixed WebSocket connection errors during multi-tab logout 💆🏽
<img width="1193" height="273" alt="Screenshot 2025-07-23 at 22 23 35"
src="https://github.com/user-attachments/assets/bf6f964d-bcb0-4a2a-adff-1194defe1e61"
/>
Previously, when users logged out in one browser tab, WebSocket
connections in other open tabs would continue trying to reconnect with
invalid authentication tokens, causing console errors and potential
runtime errors.
### What was fixed
- WebSocket connections are now properly disconnected when logout occurs
in any tab
- cross-tab logout mechanism now includes WebSocket cleanup to prevent
reconnection errors
- added logic to prevent automatic reconnection after intentional
disconnection
- added E2E tests to cover this case
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] Manual testing: Login in multiple tabs, navigate to builder
(establishes WebSocket), logout from one tab, verify no console errors
- [x] E2E test: Added automated test covering multi-tab logout with
WebSocket cleanup verification
- [x] Verified cross-tab logout still works correctly
- [x] Confirmed WebSocket connections reconnect properly after fresh
login
### For configuration changes:
None
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Ubbe <hi@ubbe.dev>
## Changes 🏗️https://github.com/user-attachments/assets/42e1c896-5f3b-447c-aee9-4f5963c217d9
There is now a 🔔 icon on the Navigation bar that shows previous agent
runs and displays real-time agent running status.
If you run an agent, the bell will show on a badge how many agents are
running. If you hover over it, a hint appears. If you click on it, it
opens a dropdown and displays the executions with their status ( _which
should match what we have in library functionality, not design-wise_ ).
I leveraged the existing APIs for this purpose. Most of the run logic is
[encapsulated on this
hook](https://github.com/Significant-Gravitas/AutoGPT/compare/dev...feat/agent-notifications?expand=1#diff-a9e7f2904d6283b094aca19b64c7168e8c66be1d5e0bb454be8978cb98526617)
and is also an independent `<AgentActivityDropdown />` component.
Clicking on an agent run opens that run in the library page.
This new functionality is covered by E2E tests 💆🏽✔️
## Checklist 📋
### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
- [x] The navigation bar layout looks good when logged out
- [x] The navigation bar layout looks good when logged in
- [x] Open an agent in the library and click `Run`
- [x] See the real-time activity of the agent running on the navigation
bar bell icon
### For configuration changes:
_No configuration changes needed._
<!-- Clearly explain the need for these changes: -->
We setup launchdarkly so now we can dynamically control which blocks are
available on the UI
### Changes 🏗️
enables the google blocks + fixes the LD .env.example for the local env
<!-- Concisely describe all of the changes made in this pull request:
-->
### Checklist 📋
#### For code changes:
- [x] I have clearly listed my changes in the PR description
- [x] I have made a test plan
- [x] I have tested my changes according to the test plan:
<!-- Put your test plan here: -->
- [x] Deploy to test environment and verify the blocks show correctly vs
are hidden when toggling Launch darlky rules
### Changes ️
The previous implementation of the `LaunchDarklyProvider` had a race
condition where it would only initialize after the user's authentication
state was fully resolved. This caused two primary issues:
1. A delay in evaluating any feature flags, leading to a "flash of
un-styled/un-flagged content" until the user session was loaded.
2. An unreliable transition from an un-flagged state to a flagged state,
which could cause UI flicker or incorrect flag evaluations upon login.
This pull request refactors the provider to follow a more robust,
industry-standard pattern. It now initializes immediately with an
`anonymous` context, ensuring flags are available from the very start of
the application lifecycle. When the user logs in and their session
becomes available, the provider seamlessly transitions to an
authenticated context, guaranteeing that the correct flags are evaluated
consistently.
### Checklist
#### For code changes:
- I have clearly listed my changes in the PR description
- I have made a test plan
- I have tested my changes according to the test plan:
**Test Plan:**
- [x] **Anonymous User:** Load the application in an incognito window
without logging in. Verify that feature flags are evaluated correctly
for an anonymous user. Check the browser console for the
`[LaunchDarklyProvider] Using anonymous context` message.
- [x] **Login Flow:** While on the site, log in. Verify that the UI
updates with the correct feature flags for the authenticated user. Check
the console for the `[LaunchDarklyProvider] Using authenticated context`
message and confirm the LaunchDarkly client re-initializes.
- [x] **Authenticated User (Page Refresh):** As a logged-in user,
refresh the page. Verify that the application loads directly with the
authenticated user's flags, leveraging the cached session and
bootstrapped flags from `localStorage`.
- [x] **Logout Flow:** While logged in, log out. Verify that the UI
reverts to the anonymous user's state and flags. The provider `key`
should change back to "anonymous", triggering another re-mount.
<details><summary>Summary of Code Changes</summary>
- Refactored `LaunchDarklyProvider` to handle user authentication state
changes gracefully.
- The provider now initializes immediately with an `anonymous` user
context while the Supabase user session is loading.
- Once the user is authenticated, the provider's context is updated to
reflect the logged-in user's details.
- Added a `key` prop to the `<LDProvider>` component, using the user's
ID (or "anonymous"). This forces React to re-mount the provider when the
user's identity changes, ensuring a clean re-initialization of the
LaunchDarkly SDK.
- Enabled `localStorage` bootstrapping (`options={{ bootstrap:
"localStorage" }}`) to cache flags and improve performance on subsequent
page loads.
- Added `console.debug` statements for improved observability into the
provider's state (anonymous vs. authenticated).
</details>
#### For configuration changes:
- `.env.example` is updated or already compatible with my changes
- `docker-compose.yml` is updated or already compatible with my changes
- I have included a list of my configuration changes in the PR
description (under **Changes**)
<details>
<summary>Configuration Changes</summary>
- No configuration changes were made. This PR relies on existing
environment variables (`NEXT_PUBLIC_LAUNCHDARKLY_CLIENT_ID` and
`NEXT_PUBLIC_LAUNCHDARKLY_ENABLED`).
</details>
---------
Co-authored-by: Lluis Agusti <hi@llu.lu>
Ubbe