I’ve been working on setting up some integration tests at work, and I’m hitting a challenge.
I first need to create some users in our test environment so that I can test other endpoints (e.g., update, delete).
Our “create user” flow uses websockets and all the other actions use HTTP requests.
Is it possible for me to set up tests that run websockets and then HTTP requests in an order I specify?
Hey @ryannewton, welcome to the Postman community!
We do not yet support mixing both HTTP and websocket requests in a single collection, for now you’ll have to have two different collections (one for account creation, one for tests) and run them separately.
Thanks @arlem for answering my question!
Hi, Running into similar issues. Cookie-based auth is handled by HTTP, and subsequent socket connections cannot share that ecosystem, relying on alot of error-prone copying and pasting.
Is there a specific reason why Socket and HTTP requests cannot be mixed?
@benwaltersdev can you share more details about your workflow?
Do you want to share cookies across HTTP and WebSocket connections?
As a workaround, you can write a test script in HTTP and save cookies/tokens in a variable and use the same in WebSocket.
Hey. My worflow is as simple as the example above!
Login is HTTP, auth and refresh cookies returned… we need to share those cookies across HTTP and sockets. Postman handles this elegantly, almost transparently, with HTTP. It’s fantastic.
Whilst we can faciliate a workaround with vars, etc… it feels like a massive hole in what is an otherwise near-perfect experience, which adds complexity and human-error, which it has otherwise been eliminated. It’s incredibly frustrating as it’s one of those small changes that makes a huge difference. It’s difficult to understand why this limitation exists.
Cheers
We have been tracking this for a long time and will prioritize this now.
Please follow the feature request here: Add Cookie on Websocket connection · Issue #10240 · postmanlabs/postman-app-support · GitHub.
Great, thanks. I really apprecaite that. Would this solution allow cookies to automatically persist between collections?
Ideally, it would be great to allow users to add websocket requests to collections alongside HTTP requests, which is specifically what I am asking, really.
Cookies are stored in the local app session, not part of a collection. Yes, HTTP and WebSocket connections will share the same cookies.
Regarding collections with HTTP and WebSocket requests, we are working on that right now, and hopefully we will have a more accurate ETA to be shared soon.
Excellent. Thank you very much!