mboynes

Haven't been able to figure this out, hopefully someone has a nice trick to make this work.

I have a User model and several other models that have user relationships. When a user is serialized directly (e.g. a controller returns just a single user), I want it to include a full set of data for the user (id, username, name, email, etc.). However, when one of the other models are serialized and they include users (by way of using protected $with = ['users']; on the model) in the serialized data, I want the users to be serialized using a subset of data (e.g. just name and id).

My current workaround is to hide the relationship using protected $hidden, create a separate attribute with a different name (e.g. users_data), include that in protected $appends, add the attribute method (e.g. getUsersDataAttribute()), and in that method I'm returning the minimal set of data. This works, but I'm hoping a more elegant solution exists.

Thanks!

@jlrdw @norbertho this looks like it might be related to password extensions (lastpass, 1password). Did you see my notes above? Give it a read, you might find an explanation for why one of you experiences the issue and not the other.

Here's what I've gathered so far, in the hope that it helps someone else connect dots that they've observed:

• I created a brand new app, used artisan ui:auth to scaffold the auth files, and have been able to replicate the issue (locally, using valet... however, I'm also experiencing this issue on a production site).
• I can replicate the issue only in chrome so far (also tried safari and firefox). I have three profiles in chrome, for three separate google accounts. I can replicate it reliably in two of the three. In the third, I cannot replicate the issue. Further, in a "guest" profile I cannot replicate it. This suggests an extension to me, though I've disabled all extensions and restarted my browser. I haven't yet gone so far as to uninstall all extensions (just one, as noted below).
  • I saw it mentioned in GitHub that 1password/lastpass may be to blame. In both chrome profiles where this bug occurs, I did have 1password installed and in the third profile I did not. I've since gone so far as to first disable the extension then uninstall it, and the problem still occurs. If 1password were to blame, I would disabling/uninstalling the extension to fix it, but regardless, this seems like a good lead.
• As mentioned in my last post, the issue only occurs if I sign in within ~10 seconds. If I wait more than 10 seconds after loading the page to sign in, it works. This, I feel, is an important clue, but I can't for the life of me do anything with it.
• I've tried switching session storage to both cookies and database (from the default file), and the problem persists in each case.
• As far as I can trace in the application, everything works perfectly and laravel attempts to send the response, which never arrives.

Currently working through the same bug. I've also noticed it in Chrome, on an app using Laravel 7, only in two of my three profiles in Chrome. I've disabled all extensions in a profile and in incognito with no success. Here's something quite strange I've noticed: if I login in under 10 seconds, it fails (perpetual loading, nothing happens, etc.). If I wait more than 10 seconds to login, the login goes through without a hitch.

Got to the bottom of this. It turns out that Vapor sets the env var QUEUE_CONNECTION to sqs by default. My events preceded deleting objects, so when the queue job ran, the objects were no longer available. I haven't figured out why this error wasn't logging anywhere, but that's a question for another day.

In my case, the simplest solution was to update my events to implement ShouldBroadcastNow instead of ShouldBroadcast to force them to use the synchronous queue.

Got to the bottom of this. It turns out that Vapor sets the env var QUEUE_CONNECTION to sqs by default. My events preceded deleting objects, so when the queue job ran, the objects were no longer available. I haven't figured out why this error wasn't logging anywhere, but that's a question for another day.

In my case, the simplest solution was to update my events to implement ShouldBroadcastNow instead of ShouldBroadcast to force them to use the synchronous queue.

Hey @tinfoilman, I haven't figured it out yet unfortunately. I fear I'm on the path you are, dd(), deploy, dd(), deploy...

My application is using Vapor with AWS, and it uses Pusher for real-time functionality.

Locally, my application is working as expected. I have several events and all of them broadcast as expected through Pusher. In addition to the application working, I can also confirm that all events are broadcasting by using the Pusher Debug Console.

I currently have one vapor environment, production. Some events are broadcasting on production, but others are not. I cannot figure out why some events are not broadcasting, and I've ripped out what's left of my hair.

I have one event in particular which is broadcasting in some contexts but not others. Specifically, this event has a "status" property which is a string of either "open", "close", or "delete". The event is dispatched in three controller methods, the resource's store(), update(), and delete() methods respectively. The event dispatches are identical aside from the status argument. The event broadcasts on a PresenceChannel.

Here's what I've tried or learned so far:

• I confirmed my pusher credentials on production using vapor tinker, and ruled this out (since some events are working, that's a nail in this coffin).
• I confirmed that the Pusher app is configured correctly by using the production API creds locally, and verified that all events work as expected and show in the Pusher Debug Console as expected.
• On production, the events which aren't working are not showing in the Pusher Debug Console. The Pusher Error Logs are all empty.
• I added several Log::debug() calls in the application in a few spots: the controller methods of events which are and are not working, the __construct() method of the event, and the broadcastOn() method of the event. Locally, all the log entries write as expected. On production, the Log::debug() call in the broadcastOn() method never fires, even on the event broadcasts which are working. The other log entries do work.
• Aside from (some of) my debugging calls, there's nothing in my vapor logs.

Thanks in advance for any suggestions and assistance!