#Issues with Pusher in production
89 messages · Page 1 of 1 (latest)
I've had those before, but currently it comes up with no console errors. First issue had to do with the unavailability of env variables in the pipeline.
Do you even see a websocket/http fallback connection to pusher at all in your network request?
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.
Mkay
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
in your JS you mean, or the backend?
Think you mentioned the backend was properly hitting pushers API
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
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
but the normal process of setting up a connection and listening on said channel does not
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
yup
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
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
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
Well your app ID will definitely be different between your dev/sandbox vs production
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
Mkay, because so far not sure I have much else to go on 😦
Might want to define wssHost
good call, let me give that a shot
lemme open up my chat app that used pusher, might see something
appreciate it a lot
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
let me check, the app I'm building is still in "testing" so no harm done
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
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?
even the docs show only defining the limited keys
Pusher is just an option to use, and my default for my public demo repo, however on my live demo, I do instead host my own using laravel-websockets
But I know locally it works as well
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
Truth be told, just been a while since I truly interacted with the real pusher, been using drop-in replacements for some time now.
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.
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
Yea, they do not define wsHost etc
in broadcasting.php ?
https://github.com/RTippin/messenger-demo demo in question.
let me take a look
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
yeah, I have to agree
My actual JS is another repo, https://github.com/RTippin/messenger-ui/blob/master/resources/js/managers/NotifyManager.js#L129-L172 so you can see that code in question
Old, shit JS, but it "works"
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
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.
oeh getting a response here now
But if you are using real pusher, do not think that would impact you
not in this cluster error now
An error is something at least lol