Replace Ably with Redis Streams by Copilot · Pull Request #717 · testdriverai/testdriverai

Copilot · 2026-03-18T04:08:34Z

Ably channel/connection/message limits were being hit at scale, and WebSocket disconnects created reliability issues. This replaces Ably entirely with Redis Streams (ioredis) for at-least-once delivery with no per-connection rate limits.

Transport layer (`agent/lib/sandbox.js`)

_initRedis(redisUrl, streamNames) — replaces _initAbly; creates two connections (publisher + XREAD reader) with shared exponential-backoff retry strategy
_startPollLoop() — single XREAD BLOCK loop across responses, files, and control streams; control starts from '0' to replay stream history, replacing Ably's channel history API for race-free runner.ready detection
_sendRedis(message, timeout) — replaces _sendAbly; publishes via XADD to the commands stream; drops Ably-specific rate limiting (_throttledPublish) entirely
_controlHandlers[] — one-shot callback array replaces Ably subscription/unsubscribe pattern for runner.ready waiting

API contract change

The API must now return reply.redis instead of reply.ably:

// Before
reply.ably.token       // Ably auth token
reply.ably.channels    // { commands, responses, control, files }

// After
reply.redis.url        // Redis connection URL (e.g. ******host:port)
reply.redis.streams    // { commands, responses, control, files }

Dependencies (`package.json`)

Removed: ably ^2.6.0
Added: ioredis ^5.10.0

Original prompt

ok implement this plan completely. remove ably completely

[Chronological Review: The conversation began with the user expressing concerns about hitting limits on Ably regarding channels, connections, and messages. The user then suggested using Redis as a queue to address issues with WebSocket disconnects, considering Redis Streams for at-least-once delivery. Finally, the user inquired about securely delivering Redis information to runners without exposing sensitive data.]

[Intent Mapping:

"we're hitting a lot of ably max channels, connections, and messages. is there a better way to architect this project to avoid those limits?" - User is seeking architectural advice to avoid limits imposed by Ably.
"we previously used websockets but were facing problems with disconnects, so we wanted a queue to sit in between" - User is looking for a solution to WebSocket disconnect issues, suggesting a queue.
"redis seems like a good answer, but we need at-least-once delivery, so maybe streams instead?" - User is considering Redis Streams for message delivery.
"can we securely deliver the redis info to the runners? how do we avoid exposing redis information?" - User is concerned about security in delivering Redis information.]

[Technical Inventory:

Ably: A real-time messaging service with limits on channels, connections, and messages.
Redis: An in-memory data structure store, used as a message broker.
Redis Streams: A feature of Redis that allows for at-least-once message delivery.]

[Code Archaeology: No specific code changes or files were discussed in detail, but the conversation revolves around architectural decisions and the use of Redis.]

[Progress Assessment: The user has identified the need for a new architecture to handle message delivery and is exploring Redis as a potential solution. They are also considering security implications.]

[Context Validation: The conversation has covered the user's challenges with Ably, their exploration of Redis for message queuing, and concerns about securely delivering Redis information.]

[Recent Commands Analysis:

Last Agent Commands: No specific agent commands were executed in this session; the user provided requests and context.
Tool Results Summary: The conversation has not involved tool executions that returned results.
Pre-Summary State: The agent was actively discussing architectural solutions for message delivery and security concerns regarding Redis.
Operation Context: The user is seeking to improve their project's architecture to avoid limits and ensure secure data handling.]

1. Conversation Overview: - Primary Objectives: - "we're hitting a lot of ably max channels, connections, and messages. is there a better way to architect this project to avoid those limits?" - "we previously used websockets but were facing problems with disconnects, so we wanted a queue to sit in between." - "redis seems like a good answer, but we need at-least-once delivery, so maybe streams instead?" - "can we securely deliver the redis info to the runners? how do we avoid exposing redis information?" - Session Context: The user is exploring architectural changes to address messaging limits and reliability issues in their project, particularly focusing on Redis as a solution. - User Intent Evolution: The user started with a general inquiry about architectural improvements, moved to specific technologies (Redis), and concluded with security concerns regarding data delivery.

Technical Foundation:

Ably: A real-time messaging service with limitations on channels and connections.
Redis: An in-memory data structure store, proposed for use as a message queue.
Redis Streams: Suggested for at-least-once message delivery.

Codebase Status:

No specific files or code changes were discussed in detail.

Problem Resolution:

Issues Encountered: Limits on Ably channels and connections, WebSocket disconnects.
Solutions Implemented: Exploring Redis as a potential solution for message queuing.
Debugging Context: Ongoing discussions about the reliability of message delivery and security concerns.

Progress Tracking:

Completed Tasks: Identification of issues with current architecture and exploration of Redis.
Partially Complete Work: No specific tasks have been completed yet; the user is still in the exploration phase.
Validated Outcomes: None yet, as the user is still assessing potential solutions.

Active Work State:

Current Focus: Discussing the architecture for message delivery and security of Redis information.
Recent Context: The user has been exploring Redis as a solution to their messaging issues and is concerned about securely delivering Redis information.
Working Code: No specific code snippets were discussed recently.
Immediate Context: The user is addressing how to securely deliver Redis information to runners.

Recent Operations:

Last Agent Commands: No specific commands were ex...

Created from VS Code.

📱 Kick off Copilot coding agent tasks wherever you are with GitHub Mobile, available on iOS and Android.

Co-authored-by: ianjennings <318295+ianjennings@users.noreply.github.com>

socket-security · 2026-03-18T04:24:16Z

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Package	Supply Chain Security	Vulnerability	Quality	Maintenance
junit-viewer@4.11.1
esbuild@0.20.2
esbuild-plugin-fileloc@0.0.6
junit-report-builder@5.1.1
js-yaml@4.1.1 ⏵ 4.1.0		^-1
eventemitter2@6.4.9
jimp@0.22.12
http-server@14.1.1
globals@13.24.0 ⏵ 15.15.0			⁺¹
eslint@8.57.1 ⏵ 9.31.0	⁺¹		⁺¹	⁺⁴⁷
diff@8.0.3
ioredis@5.10.0
dotenv@16.6.1

View full report

socket-security · 2026-03-18T04:24:17Z

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert (click "▶" to expand/collapse)
Warn		Critical CVE: npm `form-data` uses unsafe random function in form-data for choosing boundary CVE: GHSA-fjxv-7rqg-78g4 form-data uses unsafe random function in form-data for choosing boundary (CRITICAL) Affected versions: < 2.5.4; >= 3.0.0 < 3.0.4; >= 4.0.0 < 4.0.4 Patched version: 4.0.4 From: package-lock.json → `npm/axios@1.10.0` → `npm/form-data@4.0.3` ℹ Read more on: This package \| This alert \| What is a critical CVE? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Remove or replace dependencies that include known critical CVEs. Consumers can use dependency overrides or npm audit fix --force to remove vulnerable dependencies. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/form-data@4.0.3`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Obfuscated code: npm `ioredis` is 96.0% likely obfuscated Confidence: 0.96 Location: Package overview From: package-lock.json → `npm/ioredis@5.10.0` ℹ Read more on: This package \| This alert \| What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at `support@socket.dev`. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment `@SocketSecurity ignore npm/ioredis@5.10.0`. You can also ignore all packages with `@SocketSecurity ignore-all`. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

Initial plan

ae1c699

Copilot AI assigned Copilot and ianjennings Mar 18, 2026

Copilot started work on behalf of ianjennings March 18, 2026 04:08 View session

feat: remove Ably and replace with Redis Streams for sandbox messaging

c47d9f9

Co-authored-by: ianjennings <318295+ianjennings@users.noreply.github.com>

Copilot AI changed the title ~~[WIP] Remove Ably integration from the project~~ Replace Ably with Redis Streams Mar 18, 2026

Copilot AI requested a review from ianjennings March 18, 2026 04:24

Copilot finished work on behalf of ianjennings March 18, 2026 04:24

Navigation Menu

Uh oh!

Replace Ably with Redis Streams - #717

Replace Ably with Redis Streams#717
ianjennings with Copilot wants to merge 2 commits into
mainfrom
copilot/remove-ably-completely

Copilot AI commented Mar 18, 2026 •

edited

Loading

Uh oh!

socket-security Bot commented Mar 18, 2026

Uh oh!

socket-security Bot commented Mar 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Copilot AI commented Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Transport layer (agent/lib/sandbox.js)

API contract change

Dependencies (package.json)

Uh oh!

socket-security Bot commented Mar 18, 2026

Uh oh!

socket-security Bot commented Mar 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Copilot AI commented Mar 18, 2026 •

edited

Loading

Transport layer (`agent/lib/sandbox.js`)

Dependencies (`package.json`)