Job recorder memory leak about telescope

[driesvints]

Gonna close this since you found a solution. Thanks

[github-actions]

Thank you for reporting this issue!

As Laravel is an open source project, we rely on the community to help us diagnose and fix issues as it is not possible to research and fix every issue reported to us via GitHub.

If possible, please make a pull request fixing the issue you have described, along with corresponding tests. All pull requests are promptly reviewed by the Laravel team.

Thank you!

[nick-potts]

for ($i = 0; $i < 5000; $i++) {
   Telescope::recordJob(new IncomingEntry(['hi' => str_repeat('a', 100000)], Str::uuid()));
}

Given this fails, I think this is more a problem with the fact telescope will store unlimited amounts of entries before running store. In my case, I often have to queue 20k jobs in local development. The job dispatching often runs out of memory around 10k jobs.

Would a max queue length make sense for telescope?

[nick-potts]

I have solved it myself via :

    Telescope::$afterRecordingHook = function () {
            if (count(Telescope::$entriesQueue) > 1000) {
                Telescope::store(app(EntriesRepository::class));
            }
        };

It does seem like a bit of a footgun that wouldn't hurt to have some rails on it. Don't mind writing the pull request if you want a max queue size variable.

[beliven-daniele-sarnari]

This should be implemented by a config @nick-potts

[alekseyp]

What solution? Disable job watcher?
C'mon...

[driesvints]

I don't think the above scenario is a realistic one for a real-world application sorry. Dispatching 5000 jobs in a row most likely is better refactored to a different way where you can spread out the dispatching over multiple requests. We're still open to PR's to improve this.

[alekseyp]

We dispatch way less jobs and our app still goes OOM when telescope is attached.
I don't think this issue should have been closed since it's a massive headache. And if you google it a you will see how many people struggle with it.

I don't see why should we change how many jobs one command (not request) creates

[nick-potts]

Another, more real-world, scenario where php can crash due to running out of memory is the query watcher.

If you run many queries in the same request/job, it'll never flush and can run through the available memory quite quickly.

I can potentially write a PR, just not sure how best to implement it.