array_replace_recursive(): Argument #1 is not an array

[mickeyfmann]

Currently Running Laravel v5.8.35 with Waavi/Translation 2.3.4. Cache is enabled but initial loading is from file only, we're not running it with database or mixed mode enabled. Randomly getting this error in production only, haven't been able to reproduce locally or in production-like environments.

Stack Traces always point back to:
/home/forge/default/vendor/waavi/translation/src/Loaders/Loader.php:42 Illuminate\View\Engines\CompilerEngine::handleViewException

We've actually been seeing this error for a while but had attributed it to Session timeouts because locale is stored in the session. However, we just saw it today on an initial page load without a session.

My thoughts are something around the Caching system but I'm still unable to reproduce. Curious if anyone has encountered this error before and just looking for some input. I've thought about just disabling the Cache feature but I'm worried about performance.

[bilalaslam777]

@mickeyfmann i am facing the same problem. Can you please share the solution if you found any?

[xicond]

happen on me

this library suppose cast to array when loadSource not found or null

I'm searching another library

[mickeyfmann]

Unfortunately I've still not found a solution to this. I'm not able to reproduce the issue in any manual fashion, so its really hard for me to pinpoint. @bilalaslam777 @xicond , if you've encountered these issues perhaps its worth posting some more details about your setup and configuration around the library.

As I stated, our setup is running in file only mode. Our servers are provisioned with Laravel Forge and we're using the local Redis instances from that for data caching. Session data is stored on a remote Redis server, but nothing related to this should be stored there.

[mickeyfmann]

A bit of an update, @xicond your type casting comment gave me something to look at here. I delved a bit deeper to find that the issue is with the cache loader. I still haven't been able to reproduce the issue organically, but my assumption at this point is that there's a corner case just when the cache is about to expire where the cache loader check passes but the retrieval fails. Since they're returning from the tagged cache repository directly that result can be null. Regardless of how the issue is happening the problem definitely is the cache loader returning null values in some instances.

With this in mind, this gives us two options for a resolution. The first would be to disable caching via the package's config file. This will solve the issue but I was concerned with potential performance implications from this solution. So I decided to take a different path by overriding the cache loader as well as their service provider so that I could insert my custom cache loader into the mix. The only real change to the cache loader is some additional checks to ensure that the value its returning is an array. If not, it will just rely on the fallback option of the file loader again and repopulate the cache. Additionally, I'm increasing the cache time out value to 24 hours to reduce the frequency of this happening. Increasing the cache expiration settings, may not work in all cases if you're using database mode or other methods to update your content. In my case, we're running in file only mode and our deployment scripts are programmed to flush the translation cache anyways.

It should be pointed out that these are only temporary solutions, its pretty obvious at this point that this library is no longer maintained. Long term I'm going to be either looking to replace it or see if it's even necessary anymore with the improvements Laravel has made to their translation support.

[krychu90]

I have the same problem. Random errors on production.