{ "interval": { "intervalStart": "2025-10-27T00:00:00.000Z", "intervalEnd": "2025-10-28T00:00:00.000Z", "intervalType": "day" }, "repository": "elizaos/eliza", "overview": "From 2025-10-27 to 2025-10-28, elizaos/eliza had 5 new PRs (3 merged), 0 new issues, and 6 active contributors.", "topIssues": [ { "id": "I_kwDOMT5cIs7T3bkB", "title": "Implement unified messaging API through ElizaOs Wrapper", "author": "linear", "number": 6096, "repository": "elizaos/eliza", "body": "", "createdAt": "2025-10-26T22:45:35Z", "closedAt": "2025-10-27T11:57:32Z", "state": "CLOSED", "commentCount": 0 } ], "topPRs": [ { "id": "PR_kwDOMT5cIs6vzbkP", "title": "feat(server): Jobs API for one-off agent messaging with middleware refactor", "author": "wtfsayo", "number": 6098, "body": "## Summary\n\nThis PR implements a **Jobs API** for one-off messaging functionality, enabling external systems to send single messages to agents and poll for responses without maintaining persistent sessions. This is ideal for stateless integrations similar to SDK patterns.\n\nAdditionally, this PR **refactors the middleware architecture** into a modular structure for better maintainability and reusability.\n\n---\n\n## ๐Ÿ“Š Scope\n\n- **28 files changed**: +4,592 insertions, -409 deletions\n- **Net addition**: ~4,183 lines (implementation, tests, docs, examples)\n\n---\n\n## ๐Ÿš€ Core Features\n\n### Jobs API Implementation\n- **Server Router** (`packages/server/src/api/messaging/jobs.ts` - 681 lines)\n - `POST /api/messaging/jobs` - Create a new job (send message to agent)\n - `GET /api/messaging/jobs/:jobId` - Poll job status and retrieve result \n - `GET /api/messaging/jobs` - List all jobs (admin/debugging)\n - `GET /api/messaging/jobs/health` - Health check endpoint\n\n- **API Client Service** (`packages/api-client/src/services/jobs.ts` - 423 lines)\n - Full TypeScript client with type-safe methods\n - Integrated into `ElizaClient` as `client.jobs`\n - Built-in polling and retry logic\n\n### Key Capabilities\nโœ… **Automatic agent selection** - Uses first available agent if not specified \nโœ… **Configurable timeouts** - Default: 30s, Max: 5 minutes \nโœ… **In-memory job storage** - With automatic cleanup to prevent memory leaks \nโœ… **Job status tracking** - `pending โ†’ processing โ†’ completed/failed/timeout` \nโœ… **Metadata support** - Custom tracking fields \nโœ… **Intelligent message handling** - Filters intermediate action messages, waits for final result \nโœ… **Memory leak prevention** - Max 10k jobs with automatic cleanup \n\n### Message Flow\n1. Client creates job via POST request\n2. System creates temporary channel for job isolation\n3. User message is sent to channel and emitted to internal message bus\n4. Agent processes message via normal flow and responds\n5. Response is captured and stored in job result (filters out \"Executing action...\" intermediate messages)\n6. Client polls GET endpoint to retrieve result\n7. Job auto-expires and cleans up after timeout\n\n---\n\n## ๐Ÿ—๏ธ Middleware Refactor\n\nConsolidated middleware from a single monolithic file into a modular structure:\n\n**Before**: `packages/server/src/api/shared/middleware.ts` (331 lines - deleted)\n\n**After**: `packages/server/src/middleware/` directory structure:\n- `auth.ts` (40 lines) - Authentication middleware\n- `rate-limit.ts` (141 lines) - Rate limiting with in-memory store\n- `security.ts` (81 lines) - Security headers and CORS\n- `validation.ts` (119 lines) - Request validation utilities\n- `index.ts` (27 lines) - Barrel exports\n\n**Total**: 408 lines across 5 focused modules\n\n**Benefits**:\n- Better separation of concerns\n- Easier to test individual middleware\n- More maintainable and extensible\n- Clearer imports throughout the codebase\n\n---\n\n## ๐Ÿ“˜ Type Definitions\n\n**New types** (`packages/server/src/types/jobs.ts` - 171 lines, `packages/api-client/src/types/jobs.ts` - 167 lines):\n```typescript\nenum JobStatus {\n PENDING = 'pending',\n PROCESSING = 'processing', \n COMPLETED = 'completed',\n FAILED = 'failed',\n TIMEOUT = 'timeout'\n}\n\ninterface CreateJobRequest {\n agentId?: UUID;\n userId: UUID;\n content: string;\n metadata?: Record;\n timeoutMs?: number;\n}\n\ninterface JobResult {\n message: {\n content: string;\n processingTimeMs: number;\n };\n}\n\ninterface JobDetailsResponse {\n jobId: string;\n status: JobStatus;\n result?: JobResult;\n error?: string;\n createdAt: number;\n expiresAt: number;\n metadata?: Record;\n}\n```\n\n---\n\n## ๐Ÿงช Test Coverage (1,523 lines)\n\n### Server Unit Tests (`packages/server/src/api/messaging/__tests__/jobs.test.ts` - 589 lines)\n- โœ… Job creation (with/without agent ID)\n- โœ… Auto agent selection\n- โœ… Job status polling\n- โœ… Job listing and filtering\n- โœ… Health check endpoint\n- โœ… Timeout handling\n- โœ… Validation (missing fields, invalid UUIDs, timeout limits)\n- โœ… Error scenarios (agent not found, creation failures)\n- โœ… Cleanup mechanisms\n- โœ… Job expiration\n\n### Server Integration Tests (`packages/server/src/__tests__/integration/jobs-message-flow.test.ts` - 335 lines)\n- โœ… End-to-end message bus integration\n- โœ… Real agent response capture\n- โœ… Message filtering (ignores \"Executing action...\" intermediate messages)\n- โœ… Timeout scenarios with message bus\n- โœ… Cleanup and listener removal\n\n### API Client Tests (`packages/api-client/src/__tests__/services/jobs.test.ts` - 599 lines)\n- โœ… All JobsService methods\n- โœ… Request validation\n- โœ… Error handling\n- โœ… Response parsing\n- โœ… Client integration\n\n### Middleware Tests\n- โœ… Auth middleware unit tests\n- โœ… Middleware composition tests\n\n---\n\n## ๐Ÿ“š Documentation & Examples\n\n### Comprehensive Guide (`docs/jobs-api-examples.md` - 475 lines)\n**10 detailed usage examples**:\n1. Minimal request (no agent ID)\n2. With specific agent\n3. With metadata and custom timeout\n4. Shell script with polling\n5. JavaScript/Node.js implementation\n6. Python implementation\n7. TypeScript with retry logic\n8. Batch questions\n9. Robust error handling\n10. React Hook\n\n**Languages covered**: Shell, JavaScript, TypeScript, Python, React\n\n### Runnable Examples\n- **SDK-Style Client** (`examples/jobs-api-example.ts` - 324 lines)\n - `JobsAPIClient` class with built-in polling\n - Multiple integration patterns\n - JWT authentication example\n - Error handling and retry logic\n\n- **API Client Example** (`examples/jobs-api-client-example.ts` - 314 lines)\n - Uses official `@elizaos/api-client` \n - Demonstrates `ElizaClient.jobs` service\n - Shows TypeScript best practices\n\n---\n\n## ๐Ÿ”Œ API Usage Example\n\n```bash\n# Create a job\ncurl -X POST http://localhost:3000/api/messaging/jobs \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"userId\": \"user-uuid\",\n \"content\": \"What is Bitcoin price?\"\n }'\n\n# Response\n# {\n# \"jobId\": \"abc123...\",\n# \"status\": \"processing\",\n# \"createdAt\": 1234567890,\n# \"expiresAt\": 1234597890\n# }\n\n# Poll for result\ncurl http://localhost:3000/api/messaging/jobs/abc123...\n\n# Response (when completed)\n# {\n# \"jobId\": \"abc123...\",\n# \"status\": \"completed\",\n# \"result\": {\n# \"message\": {\n# \"content\": \"Bitcoin is currently trading at...\",\n# \"processingTimeMs\": 2341\n# }\n# }\n# }\n```\n\n---\n\n## ๐Ÿ”ง Technical Implementation Details\n\n### Memory Management\n- Jobs expire after configured timeout (default 30s, max 5 minutes)\n- Cleanup runs every 60 seconds to remove completed/expired jobs\n- Emergency cleanup at 10k jobs (removes oldest 10%)\n- Message bus listeners auto-cleanup after timeout + 5s buffer\n- Metrics tracking for job counts and cleanup operations\n\n### Integration Points\n- Integrated with existing messaging router\n- Uses internal message bus for agent communication\n- Creates temporary channels for job isolation\n- Filters out intermediate \"Executing action...\" messages\n- Captures only final agent responses\n\n---\n\n## โš ๏ธ Testing Notes\n\n**Authentication temporarily disabled** for initial testing/development\n- Need to re-enable `requireAuthOrApiKey` middleware before merging to production\n- See TODO comments in `jobs.ts`\n\n---\n\n## ๐Ÿ“‹ Next Steps\n\n- [ ] Re-enable authentication middleware\n- [ ] Consider database persistence (optional - currently in-memory is sufficient)\n- [ ] Consider WebSocket notifications for real-time updates (optional enhancement)\n- [ ] Add rate limiting per user/agent\n- [ ] Add metrics/monitoring integration\n\n---\n\n## ๐Ÿ”— Related\n\n- Feature branch: `jobs-api`\n- Implements one-off messaging pattern similar to external SDK integrations\n- Part of broader effort to provide multiple client integration patterns (sessions, jobs, websockets)\n\n---\n\n## ๐ŸŽฏ Key Files Summary\n\n**Server Implementation:**\n- `packages/server/src/api/messaging/jobs.ts` (681 lines) - Main API router\n- `packages/server/src/types/jobs.ts` (171 lines) - Server-side types\n- `packages/server/src/middleware/*` (408 lines) - Refactored middleware modules\n\n**API Client:**\n- `packages/api-client/src/services/jobs.ts` (423 lines) - Jobs service client\n- `packages/api-client/src/types/jobs.ts` (167 lines) - Client-side types\n\n**Tests:**\n- Server unit: 589 lines\n- Server integration: 335 lines \n- Client unit: 599 lines\n- **Total test coverage: 1,523 lines**\n\n**Documentation & Examples:**\n- `docs/jobs-api-examples.md` (475 lines)\n- `examples/jobs-api-example.ts` (324 lines)\n- `examples/jobs-api-client-example.ts` (314 lines)\n- **Total documentation: 1,113 lines**\n\n\n---\n\n> [!NOTE]\n> Adds a Jobs API with server endpoints and a client SDK (with polling/backoff), integrates it into messaging, introduces modular middleware, and includes types, docs, examples, and tests.\n> \n> - **Backend (server)**:\n> - **Jobs API**: New router `api/messaging/jobs.ts` with `POST /jobs`, `GET /jobs/:jobId`, `GET /jobs`, `GET /jobs/health`; integrated into `messagingRouter`.\n> - Per-router in-memory jobs, timeouts/cleanup, metrics, API key auth, temporary channels, internal bus emission, and action-message filtering.\n> - Types added in `types/jobs.ts`; mounted and wired across server; security headers and minor route handling tweaks.\n> - **Middleware**:\n> - Refactor to modular `middleware/` (`auth`, `rate-limit`, `security`, `validation`, `index`) and update imports across server; add/expand tests.\n> - **API Client (@elizaos/api-client)**:\n> - New `JobsService` (`create`, `getJob`, `list`, `health`, `poll`, `createAndPoll`, `createAndPollWithBackoff`, `ask`) with types; exposed on `ElizaClient` and `index`.\n> - README updated with Jobs usage.\n> - **Docs & Examples**:\n> - Add `docs/jobs-api-examples.md` and runnable examples `examples/jobs-api-*.ts`.\n> - **Tests**:\n> - Add comprehensive server unit/integration tests for Jobs and middleware; add client `JobsService` tests.\n> \n> Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 1f9905a5ccdbc895286757935364f6ee53e83d85. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).\n", "repository": "elizaos/eliza", "createdAt": "2025-10-27T05:27:00Z", "mergedAt": "2025-10-27T16:44:57Z", "additions": 4610, "deletions": 409 }, { "id": "PR_kwDOMT5cIs6v8hih", "title": "feat(server): Add x402 payment middleware to Jobs API", "author": "wtfsayo", "number": 6099, "body": "## Summary\n\nThis PR adds x402 payment middleware integration to the Jobs API, enabling cryptocurrency payments for AI agent access.\n\n## Key Features\n\n### Flexible Authentication Modes\n- **Both API key + x402 enabled**: Requires BOTH `X-API-KEY` AND `X-PAYMENT` headers\n- **Only API key** (x402=false): Requires only `X-API-KEY` header \n- **Only x402** (no API token): Requires only `X-PAYMENT` header\n- **Neither enabled**: No authentication required\n\n### Environment-Based Configuration\nAll settings via `.env` variables:\n- `X402_ENABLED` - Enable/disable payment middleware\n- `X402_WALLET_ADDRESS` - Receiving wallet address\n- `X402_PRICE` - Price in USDC (default: $0.01)\n- `X402_NETWORK` - Blockchain network (default: base-sepolia)\n- `X402_USE_MAINNET` - Use CDP facilitator for production\n- `CDP_API_KEY_ID`/`CDP_API_KEY_SECRET` - Required for mainnet\n\n### Auto-Discovery\nEndpoints automatically listed in x402 Bazaar (mainnet) with:\n- Full JSON schemas (input/output)\n- Descriptive documentation\n- Pricing information\n\n## Files Changed\n\n### New Files\n- `packages/server/src/middleware/x402.ts` - Main middleware implementation\n- `packages/server/src/middleware/__tests__/x402.test.ts` - Comprehensive test suite (12 tests)\n- `docs/x402-payment-integration.md` - Full documentation\n\n### Modified Files \n- `packages/server/src/middleware/index.ts` - Export x402 middleware\n- `packages/server/src/api/messaging/jobs.ts` - Integrated x402 on POST /jobs route\n- `packages/server/package.json` - Added x402 dependencies\n- `bun.lock` - Lockfile update\n\n## Dependencies Added\n- `x402-express@0.7.0` - Express middleware for x402 protocol\n- `@coinbase/x402@0.7.0` - CDP facilitator for mainnet\n\n## Testing\n\nโœ… All 12 unit tests passing \nโœ… Build successful\nโœ… No linter errors\nโœ… TypeScript types validated\n\nRun tests:\n```bash\ncd packages/server\nbun test src/middleware/__tests__/x402.test.ts\n```\n\n## Documentation\n\nSee `docs/x402-payment-integration.md` for:\n- Complete setup instructions\n- Configuration examples\n- Testing guide\n- Security considerations\n- Troubleshooting\n\n## Breaking Changes\n\nNone - x402 is disabled by default and completely optional.\n\n## References\n\n- [x402 Protocol Docs](https://docs.cdp.coinbase.com/x402/)\n- [x402 Quickstart for Sellers](https://docs.cdp.coinbase.com/x402/quickstart-for-sellers)\n- [Coinbase Developer Platform](https://cdp.coinbase.com)\n\n\n---\n\n> [!NOTE]\n> Integrates x402 crypto payments into POST /api/messaging/jobs with env-configurable pricing/networks, adds docs/tests, and required dependencies.\n> \n> - **Server/Middleware**:\n> - Add x402 payment middleware `createX402Middleware` and `x402LoggingMiddleware` in `packages/server/src/middleware/x402.ts`; export via `middleware/index.ts`.\n> - Supports dual auth: API key and/or x402 (`X-API-KEY`, `X-PAYMENT`) with env-based config (`X402_*`, `CDP_*`).\n> - **API**:\n> - Protect `POST /api/messaging/jobs` using x402; includes route metadata (input/output schemas) for Bazaar discovery.\n> - **Docs/Tests**:\n> - Add `docs/x402-payment-integration.md` with setup, modes, and examples.\n> - Add unit tests `packages/server/src/middleware/__tests__/x402.test.ts`.\n> - **Dependencies**:\n> - Add `x402-express`, `@coinbase/x402`; update `packages/server/package.json`.\n> \n> Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 57ae3cf5914a740335e67133ada19951df0125e5. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).\n", "repository": "elizaos/eliza", "createdAt": "2025-10-27T17:07:39Z", "mergedAt": null, "additions": 4066, "deletions": 262 }, { "id": "PR_kwDOMT5cIs6vzY-q", "title": "feat: Add Jobs API for one-off agent messaging", "author": "wtfsayo", "number": 6097, "body": "## Summary\nThis PR adds a Jobs API for one-off agent messaging, similar to the @bankr/sdk pattern. This provides a simple, stateless way to send messages to agents and poll for responses without managing sessions.\n\n## New Endpoints\n\n- `POST /api/messaging/jobs` - Create one-off job to send message to agent\n- `GET /api/messaging/jobs/:jobId` - Poll for job status and response\n- `GET /api/messaging/jobs` - List all jobs (admin)\n- `GET /api/messaging/jobs/health` - Health check endpoint\n\n## Key Features\n\nโœ… **Auto-agent selection** - Uses first available agent if no `agentId` provided\nโœ… **Smart action detection** - Waits for action results, not just 'Executing action' messages\nโœ… **Automatic cleanup** - Expired jobs auto-removed (max 10k in memory)\nโœ… **Configurable timeouts** - Default: 30s, Max: 5min\nโœ… **Status tracking** - `pending` โ†’ `processing` โ†’ `completed`/`failed`/`timeout`\nโœ… **No auth required** - Can be re-enabled via middleware\n\n## Files Added\n\n- `packages/server/src/api/messaging/jobs.ts` - Jobs router implementation\n- `packages/server/src/types/jobs.ts` - TypeScript types for jobs\n- `packages/server/src/types/index.ts` - Type exports\n- `examples/jobs-api-example.ts` - SDK-style client examples\n- `docs/jobs-api.md` - Full API documentation\n- `docs/jobs-api-examples.md` - 10 comprehensive usage examples\n\n## Testing\n\nTested with live agent queries:\n- โœ… Bitcoin price query - Response: `Bitcoin is trading at $115,463 right now, up 3.6% in the last 24h` (6.2s)\n- โœ… Ethereum price query - Response: `ETH is trading at $4,229.41, up 7.3% in 24h` (6.1s)\n\n## Usage Example\n\n```bash\n# Simple request (no agentId, no auth)\ncurl -X POST http://localhost:3000/api/messaging/jobs \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"userId\": \"12345678-1234-1234-1234-123456789012\",\n \"content\": \"What is the current Bitcoin price?\"\n }'\n\n# Poll for result\ncurl http://localhost:3000/api/messaging/jobs/{jobId}\n```\n\n## Documentation\n\nSee `docs/jobs-api.md` for complete API documentation and `docs/jobs-api-examples.md` for usage examples.\n\n## Breaking Changes\n\nNone - This is a purely additive feature.\n\n\n---\n\n> [!NOTE]\n> Introduce Jobs API with create/poll endpoints, in-memory job tracking with cleanup/timeouts, action-aware responses, and docs/examples.\n> \n> - **Backend API**:\n> - **Jobs Router**: Add `POST /api/messaging/jobs`, `GET /api/messaging/jobs/:jobId`, `GET /api/messaging/jobs`, `GET /api/messaging/jobs/health` in `packages/server/src/api/messaging/jobs.ts`.\n> - In-memory job store with auto-cleanup, timeouts (default 30s, max 5m), and status transitions (`pending` โ†’ `processing` โ†’ `completed`/`failed`/`timeout`).\n> - Auto-agent selection when no `agentId`; creates temporary DM channels; listens on internal bus; ignores intermediate \"Executing action\" messages and waits for final result.\n> - **Router Mount**: Wire into messaging router in `packages/server/src/api/messaging/index.ts` via `createJobsRouter`.\n> - **Types**:\n> - Add job-related types/enums in `packages/server/src/types/jobs.ts` and export via `packages/server/src/types/index.ts`.\n> - **Docs/Examples**:\n> - Add comprehensive usage examples in `docs/jobs-api-examples.md`.\n> - Provide TS examples and lightweight SDK client in `examples/jobs-api-example.ts`.\n> \n> Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit d182b897cbeaa736041c7fa22be7499bdb1d5aa3. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).\n", "repository": "elizaos/eliza", "createdAt": "2025-10-27T05:21:09Z", "mergedAt": null, "additions": 1485, "deletions": 0 }, { "id": "PR_kwDOMT5cIs6wAm-b", "title": "feat: Add PostgreSQL Row-Level Security (RLS) multi-tenant isolation", "author": "standujar", "number": 6101, "body": "# Relates to\r\n\r\nThis PR implements database-level tenant isolation for ElizaOS using PostgreSQL Row-Level Security (RLS), enabling multiple independent ElizaOS servers to safely share a single PostgreSQL database.\r\n\r\n# Risks\r\n\r\n**Medium Risk**\r\n\r\n**What could be affected:**\r\n- Database schema migrations (new `owners` table and `owner_id` column)\r\n- PostgreSQL connection handling (new `application_name` parameter)\r\n- Server initialization flow (RLS setup during startup)\r\n- Multi-tenant deployments using PostgreSQL\r\n\r\n**Mitigation:**\r\n- RLS is **opt-in** via `ENABLE_RLS_ISOLATION=true` environment variable\r\n- Backward compatible when RLS is disabled\r\n- Automatic cleanup with `uninstallRLS()` when RLS is disabled\r\n- Comprehensive test coverage (39 unit tests)\r\n- Tested with multiple servers sharing the same database\r\n\r\n# Background\r\n\r\n## What does this PR do?\r\n\r\nThis PR adds PostgreSQL Row-Level Security (RLS) to enable secure multi-tenant isolation in ElizaOS. Key features:\r\n\r\n1. **Database-level isolation**: Uses PostgreSQL RLS policies to enforce tenant boundaries at the database layer\r\n2. **Dynamic server ID assignment**: Each server uses its `owner_id` (derived from auth token) as its `serverId` when RLS is enabled\r\n3. **Automatic RLS management**: Installs/uninstalls RLS functions and policies based on configuration\r\n4. **Complete tenant isolation**: All tables with `owner_id` column are protected by RLS policies\r\n5. **Backward compatible**: Existing deployments continue to work without changes\r\n\r\n## What kind of change is this?\r\n\r\n**Features** (non-breaking change which adds functionality)\r\n\r\n## Why are we doing this?\r\n\r\n### Problem\r\nCurrently, running multiple ElizaOS servers requires either:\r\n- Multiple separate PostgreSQL databases (expensive, complex to manage)\r\n- Sharing a database without isolation (security risk, data leakage possible)\r\n\r\n### Solution\r\nRow-Level Security provides:\r\n- **Cost efficiency**: One PostgreSQL database for multiple tenants\r\n- **Security**: Database-enforced isolation (not application-level)\r\n- **Simplicity**: No complex application logic for tenant filtering\r\n- **Performance**: RLS policies are optimized by PostgreSQL query planner\r\n\r\n### Use Cases\r\n- Development/testing with multiple server instances\r\n- Multi-tenant SaaS deployments\r\n- Cost-optimized production deployments\r\n- Shared staging environments\r\n\r\n# Documentation changes needed?\r\n\r\n**My changes require a change to the project documentation.**\r\n\r\nDocumentation should be added covering:\r\n- How to enable RLS isolation (`ENABLE_RLS_ISOLATION=true`)\r\n- Requirements (PostgreSQL database, not SQLite/PGLite)\r\n- How `owner_id` is derived from `ELIZA_SERVER_AUTH_TOKEN`\r\n- Multi-tenant deployment architecture\r\n- Migration guide for existing deployments\r\n\r\n# Testing\r\n\r\n## Where should a reviewer start?\r\n\r\n1. Review the RLS implementation in [packages/plugin-sql/src/rls.ts](packages/plugin-sql/src/rls.ts)\r\n2. Check the schema changes in [packages/plugin-sql/src/schema/owners.ts](packages/plugin-sql/src/schema/owners.ts) and [packages/plugin-sql/src/schema/agent.ts](packages/plugin-sql/src/schema/agent.ts)\r\n3. Review server initialization changes in [packages/server/src/index.ts](packages/server/src/index.ts) (lines 376-427 for RLS setup)\r\n4. Examine the test suites for RLS logic validation\r\n\r\n## Detailed testing steps\r\n\r\n### Automated Tests\r\n\r\n```bash\r\n# Run RLS unit tests (18 tests)\r\nbun test packages/plugin-sql/src/__tests__/unit/rls.test.ts\r\n\r\n# Run RLS server tests (21 tests)\r\nbun test packages/server/src/__tests__/rls-server.test.ts\r\n```\r\n\r\n**All 39 tests passing** โœ…\r\n\r\n### Manual Testing - Multi-Tenant Isolation\r\n\r\n**Setup: Two servers sharing one PostgreSQL database**\r\n\r\n1. **Server 1** (port 3000):\r\n```env\r\nENABLE_RLS_ISOLATION=true\r\nELIZA_SERVER_AUTH_TOKEN=server1-auth-token-abc123\r\nELIZA_SERVER_PORT=3000\r\n```\r\n\r\n2. **Server 2** (port 3001):\r\n```env\r\nENABLE_RLS_ISOLATION=true\r\nELIZA_SERVER_AUTH_TOKEN=server2-auth-token-xyz789\r\nELIZA_SERVER_PORT=3001\r\n```\r\n\r\n**Verification Steps:**\r\n\r\n1. Start both servers (they share the same PostgreSQL database)\r\n2. Create agents on each server:\r\n - POST to `http://localhost:3000/agents` โ†’ creates agent in tenant 1\r\n - POST to `http://localhost:3001/agents` โ†’ creates agent in tenant 2\r\n3. List agents on each server:\r\n - GET `http://localhost:3000/agents` โ†’ only shows tenant 1 agents\r\n - GET `http://localhost:3001/agents` โ†’ only shows tenant 2 agents\r\n4. Cross-tenant access attempt:\r\n - GET `http://localhost:3000/agents/{tenant2-agent-id}` โ†’ 404 Not Found โœ…\r\n5. Test all messaging APIs:\r\n - Servers, channels, sessions, messages are all isolated\r\n6. Test memories:\r\n - Each agent only accesses its own tenant's memories\r\n\r\n**Results from previous testing session:**\r\n- Complete isolation verified across all API endpoints\r\n- No cross-tenant data leakage\r\n- Messages, channels, servers, and memories properly isolated\r\n- RLS policies correctly enforced at database level\r\n\r\n### Testing with RLS Disabled (Backward Compatibility)\r\n\r\n1. Set `ENABLE_RLS_ISOLATION=false` or omit the variable\r\n2. Start server\r\n3. Verify:\r\n - Server uses default UUID `00000000-0000-0000-0000-000000000000`\r\n - No RLS policies applied\r\n - Existing functionality unchanged\r\n\r\n### Server ID Assignment Logic\r\n\r\n```typescript\r\n// When RLS enabled: serverId = owner_id\r\nconst rlsEnabled = process.env.ENABLE_RLS_ISOLATION === 'true';\r\nthis.serverId = rlsEnabled && this.rlsOwnerId\r\n ? (this.rlsOwnerId as UUID)\r\n : '00000000-0000-0000-0000-000000000000';\r\n```\r\n\r\n### Tests\r\n- `packages/plugin-sql/src/__tests__/unit/rls.test.ts` (NEW) - 18 unit tests\r\n- `packages/server/src/__tests__/rls-server.test.ts` (NEW) - 21 integration tests\r\n\r\n### Schema Updates\r\n- Multiple schema files updated to include `owner_id` foreign key\r\n\r\n# Deploy Notes\r\n\r\n## Database Changes\r\n\r\n**Migration required for existing PostgreSQL deployments:**\r\n\r\n1. New `owners` table will be created automatically\r\n2. `owner_id` column will be added to existing tables\r\n3. Existing rows will have `NULL` owner_id (works fine when RLS disabled)\r\n4. When RLS is first enabled, owner record is auto-created from auth token\r\n\r\n**No migration needed for:**\r\n- SQLite databases (RLS only works with PostgreSQL)\r\n- PGLite databases (RLS not supported)\r\n- Deployments that don't enable RLS\r\n\r\n## Deployment Instructions\r\n\r\n### Option 1: Enable RLS for new deployment\r\n```env\r\nENABLE_RLS_ISOLATION=true\r\nELIZA_SERVER_AUTH_TOKEN=your-unique-token-here\r\n```\r\n\r\n### Option 2: Keep existing behavior (default)\r\n```env\r\n# RLS disabled by default\r\n# ENABLE_RLS_ISOLATION=false\r\n```\r\n\r\n### Multi-tenant deployment\r\n1. Use same PostgreSQL database URL for all servers\r\n2. Set unique `ELIZA_SERVER_AUTH_TOKEN` for each server\r\n3. Enable `ENABLE_RLS_ISOLATION=true` on all servers\r\n4. Each server will automatically get isolated tenant\r\n\r\n## Environment Variables\r\n\r\n| Variable | Required | Default | Description |\r\n|----------|----------|---------|-------------|\r\n| `ENABLE_RLS_ISOLATION` | No | `false` | Enable RLS multi-tenant isolation |\r\n| `ELIZA_SERVER_AUTH_TOKEN` | Yes (when RLS enabled) | - | Unique token for this server/tenant |\r\n| PostgreSQL URL | Yes (when RLS enabled) | - | RLS requires PostgreSQL |\r\n\r\n## Performance Considerations\r\n\r\n- RLS policies use indexes on `owner_id` columns\r\n- PostgreSQL query planner optimizes RLS policy checks\r\n- Minimal overhead compared to application-level filtering\r\n- Recommended: Monitor query performance in production\r\n\r\n## Security Notes\r\n\r\n- **FORCE ROW LEVEL SECURITY** ensures even table owners respect policies\r\n- Owner ID derived from auth token using deterministic UUID generation\r\n- `application_name` connection parameter used for session context\r\n- All queries automatically filtered by PostgreSQL\r\n- **โš ๏ธ IMPORTANT**: RLS policies do NOT apply to PostgreSQL superuser accounts. For production deployments, use a regular database user (non-superuser) to ensure RLS policies are enforced. Superusers bypass RLS by design.\r\n\r\n---\r\n\r\n- Full backward compatibility maintained\r\n", "repository": "elizaos/eliza", "createdAt": "2025-10-27T22:55:30Z", "mergedAt": "2025-10-29T07:57:28Z", "additions": 1381, "deletions": 136 }, { "id": "PR_kwDOMT5cIs6v-oWu", "title": "feat: elizaos login CLI command", "author": "ChristopherTrimboli", "number": 6100, "body": "# feat(cli): Add cloud authentication with `elizaos login` command\n\n## Relates to\n\nImplements CLI-side authentication for ElizaOS Cloud integration.\n\n**Related PR**: [Cloud-side implementation in eliza-cloud-v2]\n\n## Risks\n\n**Risk Level**: Low-Medium\n\n**What could be affected:**\n- `.env` file handling in CLI projects (minimal risk - preserves existing vars)\n- CLI startup time (negligible - login is opt-in command)\n- User workflows (positive - adds new capability without breaking existing flows)\n\n**Mitigation:**\n- Uses existing `env` command utilities (proven, tested code)\n- Isolated to new `login` command (no changes to existing commands)\n- Graceful fallback if cloud unavailable\n- Comprehensive error handling\n\n## Background\n\n### What does this PR do?\n\nAdds a new `elizaos login` command that enables developers to authenticate their CLI with ElizaOS Cloud through a secure browser-based flow:\n\n1. **CLI generates unique session ID** using cryptographic randomness\n2. **Opens browser** to cloud authentication page (cross-platform support)\n3. **User authenticates** via Privy (or reuses existing session)\n4. **Cloud generates API key** and associates with session\n5. **CLI polls for completion** using smart exponential backoff\n6. **API key auto-saved** to project's `.env` file\n7. **Success message** displays key details and next steps\n\n**Key Benefits:**\n- ๐Ÿ” **Secure**: No credentials stored in CLI, one-time key retrieval\n- ๐Ÿš€ **Fast**: <10 seconds with existing Privy session\n- ๐Ÿ’พ **Automatic**: Writes to `.env` without manual copying\n- โœจ **Beautiful**: Colored output, spinners, clear instructions\n- ๐Ÿ›ก๏ธ **Robust**: Handles network errors, timeouts, filesystem issues\n\n### What kind of change is this?\n\n- [x] **Features** (non-breaking change which adds functionality)\n\n## Why are we doing this?\n\nEnables seamless integration between local CLI and cloud-hosted features:\n\n- Deploy agents to cloud: `elizaos deploy --remote-url https://cloud.elizaos.ai`\n- Manage cloud agents: `elizaos agent list --remote-url https://cloud.elizaos.ai`\n- Access cloud services without manual API key management\n\n**Current workflow (manual):**\n1. Visit cloud dashboard\n2. Generate API key\n3. Copy key\n4. Manually add to `.env` file\n\n**New workflow (automated):**\n1. Run `elizaos login`\n2. โœ… Done!\n\n---\n\n## Documentation changes needed?\n\n- [x] **My changes require a change to the project documentation**\n- [x] **I have updated the documentation accordingly**\n\n**Documentation added:**\n- `packages/cli/src/commands/login/README.md` - Complete CLI feature docs\n- `packages/cli/src/commands/login/` - JSDoc on all functions\n- Unit test documentation in test files\n- Help text in command definition\n\n---\n\n## Testing\n\n### Where should a reviewer start?\n\n1. **Review command structure**: `src/commands/login/index.ts`\n2. **Review main handler**: `src/commands/login/actions/login.ts`\n3. **Check utilities**: `src/commands/login/utils/`\n4. **Run unit tests**: `bun test src/commands/login`\n5. **Test help output**: `bun dist/index.js login --help`\n\n### Detailed testing steps\n\n#### Unit Tests\n\n```bash\ncd packages/cli\n\n# Run login tests\nbun test src/commands/login/__tests__/login.test.ts\n\n# Expected output:\n# โœ“ generateSessionId > should generate unique IDs\n# โœ“ generateSessionId > should generate hex strings \n# โœ“ generateSessionId > should generate 64-char strings\n# 3 pass, 0 fail\n```\n\n#### Manual Integration Testing\n\n**Prerequisites:**\n- ElizaOS Cloud running locally or in staging\n- Database migration applied on cloud side\n\n**Test 1: Happy Path**\n```bash\n# 1. Build CLI\nbun run build\n\n# 2. Run login command\nbun dist/index.js login --cloud-url http://localhost:3000\n\n# Expected:\n# - Browser opens automatically\n# - Authentication page displays\n# - After login, success message shows\n# - .env file contains ELIZA_CLOUD_API_KEY=eliza_...\n```\n\n**Test 2: No Browser Mode**\n```bash\nbun dist/index.js login --cloud-url http://localhost:3000 --no-browser\n\n# Expected:\n# - No browser opens\n# - URL displayed in terminal\n# - Manual authentication works\n# - API key saved after completion\n```\n\n**Test 3: Timeout Handling**\n```bash\nbun dist/index.js login --cloud-url http://localhost:3000 --timeout 10\n\n# Don't complete auth in browser\n\n# Expected:\n# - Waits 10 seconds\n# - Times out with clear message\n# - Suggests using --timeout flag\n```\n\n**Test 4: Error Handling**\n```bash\n# Test with invalid URL\nbun dist/index.js login --cloud-url http://invalid:9999\n\n# Expected:\n# - Retries with exponential backoff\n# - Clear error message after max retries\n# - Helpful troubleshooting suggestion\n```\n\n#### Command Help Output\n\n```bash\n$ bun dist/index.js login --help\n\n# Expected output:\n# Usage: elizaos login [options]\n# \n# Authenticate with ElizaOS Cloud to get an API key\n# \n# Options:\n# -u, --cloud-url URL of ElizaOS Cloud (default: \"http://localhost:3000\")\n# --no-browser Do not automatically open browser\n# --timeout Authentication timeout in seconds (default: \"300\")\n# -h, --help display help for command\n```\n\n### Test Coverage\n\n- โœ… **Session ID generation** - 100% coverage (3 tests)\n- โœ… **Browser opening** - Logic implemented (cross-platform)\n- โœ… **Polling logic** - Exponential backoff, timeout handling\n- โœ… **Error handling** - Network, timeout, filesystem errors\n- โœ… **.env writing** - Preserves existing variables\n\n---\n\n## Code Structure\n\n### Files Added\n\n```\npackages/cli/src/commands/login/\nโ”œโ”€โ”€ index.ts # Command definition (exported to main CLI)\nโ”œโ”€โ”€ types.ts # TypeScript interfaces\nโ”œโ”€โ”€ README.md # Complete documentation\nโ”œโ”€โ”€ actions/\nโ”‚ โ””โ”€โ”€ login.ts # Main authentication orchestration\nโ”œโ”€โ”€ utils/\nโ”‚ โ”œโ”€โ”€ index.ts # Barrel export\nโ”‚ โ”œโ”€โ”€ session.ts # Crypto-secure session ID generation\nโ”‚ โ”œโ”€โ”€ browser.ts # Cross-platform browser opener\nโ”‚ โ””โ”€โ”€ polling.ts # Smart polling with retry logic\nโ””โ”€โ”€ __tests__/\n โ””โ”€โ”€ login.test.ts # Unit tests (3 passing)\n```\n\n### Integration Points\n\n**Modified:**\n- `src/index.ts` - Registered `login` command with main CLI program\n\n**Dependencies:**\n- Reuses `env` command utilities (`writeEnvFile`, `parseEnvFile`)\n- Uses existing CLI patterns (Commander.js, yoctocolors, ora)\n- Follows established error handling patterns\n\n---\n\n## Key Implementation Decisions\n\n### 1. Session ID Generation\n**Choice**: `crypto.randomBytes(32)` โ†’ 64-char hex string \n**Why**: Cryptographically secure, prevents prediction attacks\n\n### 2. Browser Opening Strategy\n**Choice**: Platform detection with fallbacks \n**Why**: Supports macOS (`open`), Windows (`start`), Linux (`xdg-open`)\n\n### 3. Polling Mechanism\n**Choice**: 2-second interval with exponential backoff on errors \n**Why**: Balances responsiveness with server load, resilient to network issues\n\n### 4. .env File Handling\n**Choice**: Read existing vars, merge, write back \n**Why**: Preserves user's existing configuration, no data loss\n\n### 5. Error Messages\n**Choice**: Contextual errors with recovery suggestions \n**Why**: Better DX - users know exactly what to do\n\n---\n\n## Dependencies\n\n**New dependencies**: None! \n\n**Uses existing CLI dependencies:**\n- `commander` - Command framework\n- `yoctocolors` - Terminal colors\n- `ora` - Spinners\n- `node:crypto` - Secure randomness\n- `node:child_process` - Browser opening\n\n---\n\n## Breaking Changes\n\n**None.** This is a purely additive feature:\n- โœ… New command doesn't conflict with existing commands\n- โœ… No changes to existing command behavior\n- โœ… Backward compatible\n\n---\n\n## Performance Impact\n\n- **Startup time**: No impact (command loaded lazily)\n- **Build time**: +0.1s (minimal new code)\n- **Bundle size**: +3KB (utilities are small)\n- **Runtime**: Instant locally, <10s with cloud polling\n\n---\n\n## Security Review\n\n### โœ… Security Best Practices Followed\n\n1. **No credential storage** - CLI never handles user passwords\n2. **Cryptographic randomness** - `crypto.randomBytes` for session IDs\n3. **No hardcoded secrets** - Cloud URL configurable\n4. **Secure defaults** - HTTPS for production URLs\n5. **Error message safety** - No sensitive data in error logs\n6. **File permissions** - Respects system file permissions\n\n### Session Security\n- โœ… Unique, random session IDs\n- โœ… Time-limited (expires server-side after 10min)\n- โœ… Single-use (can't replay session)\n\n### API Key Security\n- โœ… Transmitted over HTTPS in production\n- โœ… Stored locally in `.env` (gitignored by default)\n- โœ… One-time retrieval from cloud (cleared after fetch)\n\n---\n\n## User Experience\n\n### CLI Output Example\n\n```bash\n$ elizaos login\n\n๐Ÿ” ElizaOS Cloud Authentication\n\nSession ID: abc123def456...\n\nOpening browser for authentication...\n\nโœ“ Browser opened successfully\n\nPlease complete authentication in your browser:\n\n http://localhost:3000/auth/cli-login?session=abc123...\n\nโœ“ Waiting for authentication... [2.3s]\nโœ“ Authentication successful!\nโœ“ API key saved to .env\n\nโœจ You are now authenticated with ElizaOS Cloud!\n\nAPI Key Details:\n Prefix: eliza_abc\n Expires: Never\n\n๐Ÿ“ Next Steps:\n โ€ข Your API key has been saved to .env\n โ€ข You can now use ElizaOS Cloud features\n โ€ข View your usage at the cloud dashboard\n```\n\n### Error Messages\n\nAll errors include:\n- โŒ Clear problem description\n- ๐Ÿ’ก Suggested solution\n- ๐Ÿ”ง Recovery steps\n\nExample:\n```\nโŒ Authentication timed out. Please try again.\n\nโฑ Try increasing the timeout:\n elizaos login --timeout 600\n```\n\n---\n\n## Backward Compatibility\n\nโœ… **100% Backward Compatible**\n\n- Existing commands unchanged\n- No new required dependencies\n- No breaking changes to `.env` handling\n- Users can opt-in at their convenience\n\n---\n\n## Future Enhancements\n\nNot in scope for this PR, but potential future additions:\n\n- `elizaos logout` - Revoke current API key\n- `elizaos whoami` - Show authenticated user\n- Device management and naming\n- Key rotation support\n\n---\n\n## Related Work\n\n**Requires companion PR in eliza-cloud-v2:**\n- Database schema for `cli_auth_sessions`\n- API endpoints for session management\n- Web UI for authentication\n- Service layer for key generation\n\n**See**: [IMPLEMENTATION_SUMMARY.md](../IMPLEMENTATION_SUMMARY.md) for complete cross-repo overview\n\n---\n\n## Testing Instructions for Reviewers\n\n### Quick Test (2 minutes)\n\n```bash\n# 1. Build CLI\ncd packages/cli\nbun run build\n\n# 2. Check help\nbun dist/index.js login --help\n\n# 3. Run unit tests\nbun test src/commands/login\n\n# Expected: All tests pass\n```\n\n### Full Integration Test (5 minutes)\n\nRequires cloud project running:\n\n```bash\n# Terminal 1: Start cloud\ncd eliza-cloud-v2\nbun dev\n\n# Terminal 2: Test login\ncd eliza/packages/cli \nbun dist/index.js login --cloud-url http://localhost:3000\n\n# Follow browser prompts\n# Verify .env file updated\ncat .env | grep ELIZA_CLOUD_API_KEY\n```\n\n---\n\n## Checklist\n\n- [x] Code follows ElizaOS style guidelines\n- [x] Self-review completed\n- [x] Comments added for complex logic\n- [x] Documentation updated\n- [x] No new warnings generated\n- [x] Unit tests added and passing\n- [x] Manual testing completed\n- [x] No breaking changes\n- [x] Follows existing patterns\n- [x] Error handling comprehensive\n\n---\n\n## Screenshots\n\n### CLI Terminal Output\n\n```\n๐Ÿ” ElizaOS Cloud Authentication\nโœ“ Browser opened successfully\nโœ“ Authentication successful!\nโœ“ API key saved to .env\nโœจ You are now authenticated with ElizaOS Cloud!\n```\n\n### Help Output\n\n```\nUsage: elizaos login [options]\n\nAuthenticate with ElizaOS Cloud to get an API key\n\nOptions:\n -u, --cloud-url URL of ElizaOS Cloud\n --no-browser Do not automatically open browser\n --timeout Authentication timeout (default: \"300\")\n -h, --help display help for command\n```\n\n---\n\n## Additional Context\n\n### Files Changed Summary\n\n- **9 new files** in `packages/cli/src/commands/login/`\n- **1 modified file**: `packages/cli/src/index.ts` (registered command)\n- **Total LOC**: ~600 lines (including docs and tests)\n\n### Build Verification\n\n```bash\n$ bun run build\nโœ… @elizaos/cli build complete!\nโฑ๏ธ Total build time: 2977.96ms\n\n$ bun test src/commands/login\nโœ“ 3 pass, 0 fail\n```\n\n---\n\n## Discord username\n\n\n\n---\n\n## Reviewer Notes\n\n**Focus areas for review:**\n\n1. **Security**: Session ID generation, API key handling\n2. **Error handling**: Network errors, timeout logic, filesystem errors \n3. **Cross-platform**: Browser opening on macOS/Linux/Windows\n4. **User experience**: Terminal output, error messages, help text\n5. **Code organization**: Command structure, utility separation\n\n**Testing priority:**\n\n1. โญ๏ธ Run unit tests (`bun test src/commands/login`)\n2. โญ๏ธ Test help output (`elizaos login --help`)\n3. โญ๏ธ Review error handling in `actions/login.ts`\n4. โšก Manual test with cloud running (optional but recommended)\n\n---\n\n## Conventional Commits\n\n```\nfeat(cli): Add cloud authentication with elizaos login command\n\n- Implements secure browser-based authentication flow\n- Generates cryptographically random session IDs\n- Cross-platform browser opening (macOS/Linux/Windows)\n- Smart polling with exponential backoff and retries\n- Automatic .env file updates preserving existing variables\n- Comprehensive error handling with recovery suggestions\n- Beautiful terminal UI with colors and spinners\n- Complete documentation and unit tests\n\nPart of the ElizaOS Cloud integration initiative.\nRequires companion PR in eliza-cloud-v2 for full functionality.\n```\n\n---\n\n**Ready for review!** ๐Ÿš€\n\nThis PR contains only the CLI-side implementation. The cloud-side implementation (API endpoints, database, web UI) is in a separate PR for the eliza-cloud-v2 repository.\n\n", "repository": "elizaos/eliza", "createdAt": "2025-10-27T19:55:00Z", "mergedAt": "2025-10-27T20:14:33Z", "additions": 1044, "deletions": 513 } ], "codeChanges": { "additions": 6606, "deletions": 1278, "files": 46, "commitCount": 40 }, "completedItems": [ { "title": "feat: implement unified messaging API with elizaOS.sendMessage()", "prNumber": 6095, "type": "feature", "body": "# Relates to\n\nThis PR addresses the need for a unified messaging API across all ElizaOS clients to eliminate code duplication and improve maintainability.\n\n# Risks\n\n**Risk Level: Medium**\n\n- **Affected Areas**: Core messaging infrastructure", "files": [ "bun.lock", "packages/core/src/__tests__/elizaos-sendmessage.test.ts", "packages/core/src/__tests__/elizaos.test.ts", "packages/core/src/elizaos.ts", "packages/core/src/types/messaging.ts", "packages/server/src/index.ts", "packages/server/src/services/message.ts" ] }, { "title": "feat: elizaos login CLI command", "prNumber": 6100, "type": "feature", "body": "# feat(cli): Add cloud authentication with `elizaos login` command\n\n## Relates to\n\nImplements CLI-side authentication for ElizaOS Cloud integration.\n\n**Related PR**: [Cloud-side implementation in eliza-cloud-v2]\n\n## Risks\n\n**Risk Level**: L", "files": [ "bun.lock", "packages/cli/src/commands/deploy/actions/deploy-ecs.ts", "packages/cli/src/commands/deploy/utils/docker-build.ts", "packages/cli/src/commands/login/README.md", "packages/cli/src/commands/login/__tests__/login.test.ts", "packages/cli/src/commands/login/actions/login.ts", "packages/cli/src/commands/login/index.ts", "packages/cli/src/commands/login/types.ts", "packages/cli/src/commands/login/utils/browser.ts", "packages/cli/src/commands/login/utils/index.ts", "packages/cli/src/commands/login/utils/polling.ts", "packages/cli/src/commands/login/utils/session.ts", "packages/cli/src/index.ts", "packages/core/src/__tests__/elizaos-sendmessage.test.ts", "packages/core/src/elizaos.ts", "packages/server/src/__tests__/integration/jobs-message-flow.test.ts", "packages/server/src/api/index.ts", "packages/server/src/api/messaging/__tests__/jobs.test.ts", "packages/server/src/api/messaging/channels.ts", "packages/server/src/api/messaging/jobs.ts", "packages/server/src/index.ts", "packages/server/src/middleware/auth.ts", "packages/server/src/middleware/index.ts", "packages/server/src/middleware/rate-limit.ts", "packages/server/src/middleware/security.ts", "packages/server/src/middleware/validation.ts", "packages/server/src/types/index.ts", "packages/server/src/types/jobs.ts" ] }, { "title": "feat(server): Jobs API for one-off agent messaging with middleware refactor", "prNumber": 6098, "type": "feature", "body": "## Summary\n\nThis PR implements a **Jobs API** for one-off messaging functionality, enabling external systems to send single messages to agents and poll for responses without maintaining persistent sessions. This is ideal for stateless integ", "files": [ "docs/jobs-api-examples.md", "examples/jobs-api-client-example.ts", "examples/jobs-api-example.ts", "packages/api-client/README.md", "packages/api-client/src/__tests__/services/jobs.test.ts", "packages/api-client/src/client.ts", "packages/api-client/src/index.ts", "packages/api-client/src/services/jobs.ts", "packages/api-client/src/types/jobs.ts", "packages/server/src/__tests__/authMiddleware.test.ts", "packages/server/src/__tests__/integration/jobs-message-flow.test.ts", "packages/server/src/__tests__/middleware.test.ts", "packages/server/src/api/audio/processing.ts", "packages/server/src/api/index.ts", "packages/server/src/api/messaging/__tests__/jobs.test.ts", "packages/server/src/api/messaging/channels.ts", "packages/server/src/api/messaging/index.ts", "packages/server/src/api/messaging/jobs.ts", "packages/server/src/api/shared/index.ts", "packages/server/src/api/shared/middleware.ts", "packages/server/src/index.ts", "packages/server/src/middleware/auth.ts", "packages/server/src/middleware/index.ts", "packages/server/src/middleware/rate-limit.ts", "packages/server/src/middleware/security.ts", "packages/server/src/middleware/validation.ts", "packages/server/src/types/index.ts", "packages/server/src/types/jobs.ts" ] } ], "topContributors": [ { "username": "wtfsayo", "avatarUrl": "https://avatars.githubusercontent.com/u/82053242?u=98209a1f10456f42d4d2fa71db4d5bf4a672cbc3&v=4", "totalScore": 133.01381213109784, "prScore": 132.81381213109785, "issueScore": 0, "reviewScore": 0, "commentScore": 0.2, "summary": "wtfsayo: Focused on significant feature development, notably merging a large PR in elizaos/eliza (#6098) that introduced a Jobs API for one-off agent messaging, demonstrating a primary focus on new feature work and other development tasks." }, { "username": "ChristopherTrimboli", "avatarUrl": "https://avatars.githubusercontent.com/u/27584221?u=0d816ce1dcdea8f925aba18bb710153d4a87a719&v=4", "totalScore": 64.5437738965761, "prScore": 59.5437738965761, "issueScore": 0, "reviewScore": 5, "commentScore": 0, "summary": "ChristopherTrimboli: Focused on feature development, successfully merging a significant PR in elizaos/eliza (#6100) that introduced a new CLI login command, demonstrating a primary focus on new functionality and some test work." }, { "username": "standujar", "avatarUrl": "https://avatars.githubusercontent.com/u/16385918?u=718bdcd1585be8447bdfffb8c11ce249baa7532d&v=4", "totalScore": 59.7437738965761, "prScore": 59.5437738965761, "issueScore": 0, "reviewScore": 0, "commentScore": 0.2, "summary": "standujar: Focused on significant feature development, successfully merging a substantial PR in elizaos/eliza (#6101) that added PostgreSQL Row-Level Security (RLS) multi-tenant functionality, involving a large code change of +2761/-569 lines. Their work primarily centered on feature development and refactoring, with a focus on code changes." }, { "username": "github-advanced-security", "avatarUrl": "https://avatars.githubusercontent.com/in/57789?v=4", "totalScore": 18, "prScore": 0, "issueScore": 0, "reviewScore": 18, "commentScore": 0, "summary": "github-advanced-security: No activity today." }, { "username": "0xbbjoker", "avatarUrl": "https://avatars.githubusercontent.com/u/54844437?u=90fe1762420de6ad493a1c1582f1f70c0d87d8e2&v=4", "totalScore": 5, "prScore": 0, "issueScore": 0, "reviewScore": 5, "commentScore": 0, "summary": "0xbbjoker: No activity today." } ], "newPRs": 5, "mergedPRs": 3, "newIssues": 0, "closedIssues": 1, "activeContributors": 6 }