MetaMask / MetaMask/metamask-extension
Background Readiness Signal for Connection Initialization
- Dominant language
- TypeScript
- Stars
- 13.2k
- Forks
- 5.6k
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 451
Description
## Parent Epic
Part of #39102
## Source
💬 David Murdoch - [Slack Thread](https://consensys.slack.com/archives/C09ANBKHLHM/p1759955596.419199)
## Description
From source: "Background sends `chrome.runtime.sendMessage` when ready"
Implement a proactive readiness signal from the background service worker to notify the UI when it's fully initialized and ready to accept connections.
**⚠️ Validation**: This approach should be validated first before deciding on Issue #3 (Exponential Backoff Retry).
## Current State
- UI opens popup/home and immediately attempts connection
- Background may still be initializing (cold start, post-update, etc.)
- 15-second timeout may expire before background ready
- No mechanism for UI to know when background is actually available
## Proposed Changes
1. **Background Readiness Broadcast**
- Background sends message when initialization complete
- UI listens for this signal before attempting connection
2. **Fallback Timeout Preservation**
- Keep existing timeout as safety net
## Metrics to Track
- Error rate reduction
- Percentage of connections using readiness signal vs. fallback timeout
- Time from popup open to connection established
## Decision Point: Proceed with Exponential Backoff only if
- Error rate reduction insufficient
- Significant timeout failures remain
- Edge cases not covered by readiness signal
## Testing Requirements
- [ ] Test cold start (background not yet initialized)
- [ ] Test warm start (background already ready)
- [ ] Test post-update restart scenario
- [ ] Test multiple concurrent UI contexts (popup + home)
- [ ] Verify fallback timeout still works if readiness signal fails
## Success Criteria
- Background sends readiness signal on successful initializations
- UI successfully receives and acts on readiness signal
- Connection timeout errors reduced
- No increase in failed connection attempts
Contributor guide
Research direction
Trace the background service worker initialization and the UI connection attempts in the popup/home flows, focusing on chrome.runtime.sendMessage and the existing 15-second timeout. Exercise cold, warm, post-update, and concurrent popup-plus-home scenarios, including failure of the readiness signal. Done means the background broadcasts readiness, the UI acts on it, the fallback remains functional, and connection failures do not increase.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- full-stack
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100