You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
initDevices() is a one-time, pre-connect operation. Post-init device control is enableMic() / enableCam(). The transports already enforce the one-time contract: daily-js only allows startCamera() once, and DailyMediaManager.initialize() warns and returns if already initialized. PipecatClient.initDevices() does not. It accepts a second call, runs the full mediaState lifecycle again, and hands the transport a request it can't act on.
This is easy to hit and not surprising for developers to reach for initDevices() after a device failure or between connects (see pipecat-client-web-transports#243). The correct path is to always use enableMic(true) / enableCam(true) after initDevices() (or connect()) has been called, but nothing in the client steers people there.
after some digging and soul searching, I'm going a whole new way. Instead of making initDevices a one time required called (either manual or via connect()), we should make it complete sugar. For one, not all transports actually adhered to the one time only call, they just silently adhered to that contract. Two, it's not ideal API. The developer really shouldn't have to think about "have I called this yet?"
Activity
[-]`initDevices()` should refuse repeat calls[/-][+]`initDevices()` should ~refuse repeat calls~ not be required[/+][-]`initDevices()` should ~refuse repeat calls~ not be required[/-][+]`initDevices()` should not be required[/+][-]`initDevices()` should not be required[/-][+]`initDevices()` should refuse repeat calls[/+]mattieruth commentedon Nov 3, 2026
after some digging and soul searching, I'm going a whole new way. Instead of making initDevices a one time required called (either manual or via connect()), we should make it complete sugar. For one, not all transports actually adhered to the one time only call, they just silently adhered to that contract. Two, it's not ideal API. The developer really shouldn't have to think about "have I called this yet?"
I've opened #282 to detail the new approach.