#Issues with Pusher in production

89 messages · Page 1 of 1 (latest)

graceful pendant
#

Do you have any errors in your browsers JS console? Could be many things, like not using https pusher connection when your site itself is serving via https, etc.

spice pollen
graceful pendant
#

Do you even see a websocket/http fallback connection to pusher at all in your network request?

spice pollen
#

let me take a look, might be broken at this point honestly.

#

at the beginning before starting to troubleshoot I got 500 errors every x seconds

#

let me roll some changes back and see if I can get back to that.

graceful pendant
#

Mkay

spice pollen
#

yup there we go, connection failed

#

have a feeling it might have to do something with the way I set it up in broadcasting config file

graceful pendant
#

in your JS you mean, or the backend?

#

Think you mentioned the backend was properly hitting pushers API

spice pollen
#

it is, for actually broadcasting messages

#

but it's not able to subscribe itself

#

let me see if I can share some stuff that perhaps clears it up a little

graceful pendant
#

I have not used pusher directly for a good while, but at least ensure you are using the right production keys in your JS build, as well as the cluster etc

spice pollen
#

but the normal process of setting up a connection and listening on said channel does not

graceful pendant
#

On your client side you mean?

#

Check XHR/WS tabs in your network request, see if anything is reaching out to pusher, and if so, what its errors are

spice pollen
#

let me compare this to what I call out locally

#

right this is pretty strange..

#

seems like in production it calls out to a ID instead of an encrypted version of it.

#

or hashed.. not sure what the process exactly is internally

graceful pendant
#

If you click on the failed request, does it tell you why?

#

Not sure what you mean encrypter/hashed. The endpoint it hits in your browser will always be the public keys/IDs

#

only your backend that directly hits the pusher API uses the secret keys

spice pollen
#

they didn't fail, they're stuck on pending

#

but for example if the url is

#

wss://28ahe13kjd?protocol=7 etc etc

#

works

#

but in production it's like:
wss://3571835?protocol=7 etc etc

graceful pendant
#

Well your app ID will definitely be different between your dev/sandbox vs production

spice pollen
#

yes

#

but it seems like locally

#

it changes my pusher key to something else

#

while on production it takes the literal key

#

oh my.. I think I see something, one moment

graceful pendant
#

Mkay, because so far not sure I have much else to go on 😦

spice pollen
#

locally it picks the wsHost, in production it takes the key itself

#

not sure why

graceful pendant
#

Might want to define wssHost

spice pollen
#

good call, let me give that a shot

graceful pendant
#

lemme open up my chat app that used pusher, might see something

spice pollen
#

appreciate it a lot

graceful pendant
#

Seems if I use real pusher, I do not even define wsHost etc. Though my app is a demo and not been fully updated in some time

spice pollen
#

let me check, the app I'm building is still in "testing" so no harm done

graceful pendant
#

my second object is when using a drop in replacement like laravel websockets package

#

but top one being real pusher, I never defined the wsHost etc

#

hmm

spice pollen
#

still seems to resort in a timeout

#

though this is drastically different from the implementation I have currently.

#

but you did run this demo on a production environment right?

graceful pendant
#

even the docs show only defining the limited keys

graceful pendant
#

But I know locally it works as well

spice pollen
#

I see, fair fair

#

that's the issue I have haha, locally it works like a charm

#

but let me reduce this to the docs recommended structure

graceful pendant
#

Truth be told, just been a while since I truly interacted with the real pusher, been using drop-in replacements for some time now.

spice pollen
#

might be overlooking it currently

#

but do you happen to see laravel's recommended setup for the config as well?

#

since this is client side, but broadcasting happens server side I think.

graceful pendant
#

Might want to also clear your local app storage. AT least when using a drop in, if connection fails, pusher-js resorts to long polling and their local storage state messes me up

graceful pendant
spice pollen
#

in broadcasting.php ?

graceful pendant
spice pollen
#

let me take a look

graceful pendant
#

Well if your backend is hitting pusher and showing up in their dash, then your backend config should be proper

#

seems fully a client side issue to me

spice pollen
#

yeah, I have to agree

graceful pendant
#

Old, shit JS, but it "works"

spice pollen
#

alright, let me have a read through that as well

#

but I'm just quite surprised

#

console shows pretty much the exact same call to pusher

#

as locally now

graceful pendant
#

Yea, sorry I can't be of much more help. The only issue I've seen others have recently was an issue with pusher php-server backend version 7.2 not working with laravel-websockets etc.

spice pollen
#

oeh getting a response here now

graceful pendant
#

But if you are using real pusher, do not think that would impact you

spice pollen
#

not in this cluster error now

graceful pendant
#

An error is something at least lol

spice pollen
#

yeah

#

better than just a plain 500

#

this is an actual response from pusher

#

we're getting there!

#

it uh.. seems to work

#

at least, I'm getting traffic now