browsers implementations docker issue
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 65
- Forks
- 82
- PR merge metrics
- No merged PRs in 30d
Description
# Browser Implementation Tests Failing: Redis Connection DNS Resolution Error
## Summary
All browser implementation tests (Chromium, Firefox, WebKit with JS v1.x, v2.x) are failing due to DNS resolution errors when trying to connect to Redis. The error occurs before any test logic runs, indicating a networking/infrastructure issue rather than a code problem.
## Test Results
**Test Run**: `transport-3264bbee-155405-22-01-2026`
- **Total Tests**: 42
- **Passed**: 0
- **Failed**: 42 (100% failure rate)
- **All failures**: Browser implementations (chromium-js-v*, firefox-js-v*, webkit-js-v*)
## Error Details
### Error Message
```
Redis client error: Error: getaddrinfo EAI_AGAIN transport-redis
at GetAddrInfoReqWrap.onlookupall [as oncomplete] (node:dns:122:26) {
errno: -3001,
code: 'EAI_AGAIN',
syscall: 'getaddrinfo',
hostname: 'transport-redis'
}
```
### Affected Tests
- All browser-to-browser tests (webrtc transport)
- All browser-to-rust tests (webrtc-direct transport)
- Tests timeout after 180 seconds because dialer/listener cannot coordinate via Redis
### Example Logs
From `chromium-js-v1.x x chromium-js-v1.x (webrtc)`:
```
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener | Redis client error: Error: getaddrinfo EAI_AGAIN transport-redis
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__dialer | Redis client error: Error: getaddrinfo EAI_AGAIN transport-redis
[2026-01-22 15:57:32] ERROR: ✗ Test timed out after 180s
```
## Investigation
### Code Verification ✅
- **Redis Protocol**: Browser implementations correctly use `RPUSH`/`BLPOP` (Redis list operations) as per transport test framework spec
- **Base Image Inheritance**: Browser images (`chromium-js-v1.x`, `firefox-js-v1.x`, etc.) correctly inherit from base JS images (`js-v1.x`, `js-v2.x`)
- **Environment Variables**: Code correctly reads `REDIS_ADDR` environment variable (set to `transport-redis:6379`)
### Docker Configuration
From docker-compose files:
```yaml
environment:
- REDIS_ADDR=transport-redis:6379
networks:
- transport-network
```
The containers are configured to:
- Use `transport-redis:6379` as Redis address
- Connect to `transport-network` (external network)
### Root Cause Analysis
The issue appears to be a **Docker networking/DNS resolution problem**:
1. **DNS Resolution Failure**: Browser containers cannot resolve `transport-redis` hostname
- Error `EAI_AGAIN` indicates temporary DNS resolution failure
- This happens before any Redis connection attempt
2. **Network Isolation**: Browser containers (running Playwright) may have different networking behavior than Node.js containers
- Playwright runs browsers in isolated contexts
- May not have access to Docker's internal DNS
3. **Redis Service Availability**: Need to verify:
- Is Redis service running?
- Is Redis on the same Docker network?
- Can browser containers reach Redis?
## Expected Behavior
Browser implementations should:
1. Resolve `transport-redis` hostname via Docker DNS
2. Connect to Redis at `transport-redis:6379`
3. Use `RPUSH` to publish listener multiaddr
4. Use `BLPOP` to wait for listener multiaddr (dialer)
5. Exchange multiaddrs and run ping tests
## Actual Behavior
Browser implementations:
1. ❌ Cannot resolve `transport-redis` hostname
2. ❌ Cannot connect to Redis
3. ❌ Tests timeout after 180 seconds
4. ❌ 100% failure rate
## Environment
- **Test Framework**: Transport interoperability tests
- **Browser Images**:
- `transport-implementations-chromium-js-v1.x`
- `transport-implementations-chromium-js-v2.x`
- `transport-implementations-firefox-js-v1.x`
- `transport-implementations-firefox-js-v2.x`
- `transport-implementations-webkit-js-v1.x`
- `transport-implementations-webkit-js-v2.x`
- **Base Images**: Inherit from `transport-implementations-js-v1.x`, `transport-implementations-js-v2.x`
- **Docker Network**: `transport-network` (external)
## Related Code
### Browser Image Structure
```dockerfile
# BrowserDockerfile
ARG BASE_IMAGE=node-js-libp2p-head
FROM ${BASE_IMAGE}
# ... installs Playwright browsers
```
### Redis Connection Code (from base image)
```typescript
// .aegir.js
const redisAddr = process.env.REDIS_ADDR || process.env.redis_addr || 'redis:6379'
const redisClient = createClient({
url: `redis://${redisAddr}`
})
```
### Redis Protocol (correctly implemented)
```typescript
// listener.spec.ts - uses RPUSH
await redisProxy(['RPUSH', redisKey, multiaddrs[0]])
// dialer.spec.ts - uses BLPOP
const blpopResult = await redisProxy(['BLPOP', redisKey, timeoutSeconds])
```
## Questions for Investigation
1. **Is Redis service running?**
- Check: `docker ps | grep transport-redis`
- Check: `docker logs transport-redis`
2. **Network connectivity**
- Can browser containers ping Redis?
- Are browser containers on the same network as Redis?
- Does Docker DNS work for browser containers?
3. **Playwright networking**
- Do Playwright browser contexts have access to Docker network?
- Is there a proxy or network isolation issue?
4. **Comparison with Node.js**
- Do Node.js JS implementations (`js-v1.x`, `js-v2.x`) work correctly?
- What's different about browser container networking?
## Suggested Next Steps
1. Verify Redis service is running and accessible
2. Check Docker network configuration for browser containers
3. Test DNS resolution from inside browser containers
4. Compare networking behavior between Node.js and browser containers
5. Investigate if Playwright requires special network configuration
## Additional Context
- Node.js JS implementations (non-browser) may be working correctly
- This issue affects all browser implementations across all JS versions
- The Redis protocol code is correct (RPUSH/BLPOP), but containers can't reach Redis
- This is blocking browser implementation testing in CI/CD
## Test Run Details
```python
[2026-01-22 15:54:18] INFO: Running: chromium-js-v1.x x chromium-js-v1.x (webrtc)
time="2026-01-22T15:54:18+01:00" level=warning msg="No services to build"
Container chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener Creating
Container chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener Created
Container chromium-js-v1_x_x_chromium-js-v1_x__webrtc__dialer Creating
Container chromium-js-v1_x_x_chromium-js-v1_x__webrtc__dialer Created
Attaching to chromium-js-v1_x_x_chromium-js-v1_x__webrtc__dialer, chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener
Container chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener Starting
Container chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener Started
Container chromium-js-v1_x_x_chromium-js-v1_x__webrtc__dialer Starting
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener |
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener | > @libp2p/transport-interop-libp2p-1.x@1.0.0 test
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener | > aegir test -t browser -- --browser chromium
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener |
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener | build
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener |
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener | > @libp2p/transport-interop-libp2p-1.x@1.0.0 build
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener | > aegir build --bundle false
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener |
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener | [14:54:23] tsc [started]
Container chromium-js-v1_x_x_chromium-js-v1_x__webrtc__dialer Started
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__dialer |
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__dialer | > @libp2p/transport-interop-libp2p-1.x@1.0.0 test
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__dialer | > aegir test -t browser -- --browser chromium
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__dialer |
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener | [14:54:25] tsc [completed]
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener | test browser
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener | Redis client error: Error: getaddrinfo EAI_AGAIN transport-redis
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener | at GetAddrInfoReqWrap.onlookupall [as oncomplete] (node:dns:122:26) {
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener | errno: -3001,
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener | code: 'EAI_AGAIN',
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener | syscall: 'getaddrinfo',
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener | hostname: 'transport-redis'
chromium-js-v1_x_x_chromium-js-v1_x__webrtc__listener | }
```
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Docker Compose network configuration and BrowserDockerfile, then inspect .aegir.js and the listener.spec.ts and dialer.spec.ts Redis entry points. Compare browser containers with the working Node.js implementations and verify Redis availability, network membership, and DNS resolution. Done means all listed browser interoperability tests connect to Redis and complete without timing out.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, redis, typescript
- Domain
- devops, infrastructure, testing
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100