Problems with timestamps (NaNs, Invalid date)

[iShotFT]

On both staging (centos) and local (ubuntu) environment I'm having issues with the timestamps.

• On the page 'Recent Jobs' I'm always getting Runtime 'NaNs'.
• On the page 'Failed' I'm getting 'Invalid date' for 'Failed At' and 'NaNs' for 'Runtime'.

This combined with experiencing issue #366 is giving me headaches.

[cmizzi]

Same bug here... I don't have any timestamp (NaNs values) on all queued (recent and failed) jobs.

[davidruigrok]

Same issue. I think the problems occurs because horizon api returns failed_at and reserved_at as string (not as float) which can not be parsed within the vue component (result: NaNs and Invalid date) :

{{ job.failed_at ? String((job.failed_at - job.reserved_at).toFixed(3))+'s' : '-' }}

{{ readableTimestamp(job.failed_at) }}

Part of API response (/horizon/api/jobs/failed):

{"jobs": [
{
"id": "808121",
"connection": "redis",
"queue": "title:resources",
"name": "App\\Jobs\\TrackTitle",
"status": "failed",
"payload": {},
"exception": "...",
"failed_at": "1535147607,7085",
"completed_at": null,
"retried_by": [],
"reserved_at": "1535147607,6773",
"index": 0
}
]}

I have not yet figured out why failed_at and reserved_at are not set / parsed correctly in the api response. Same problems occurs with /horizon/api/jobs/recent and horizon/monitoring (detail page) API requests.

[webpatser]

I had the same some time ago. Republishing the assets did the trick then..?

[davidruigrok]

Unfortunately, republishing the assets did not solve it.
Somehow, failed_at, completed_at, and reserved_at are stored as strings instead of floats.
Within redis (for random job with id 1213931):

127.0.0.1:6379> HMGET horizon:1213931 id connection status exception failed_at completed_at retried_by reserved_at
 1) "1213931"
 2) "redis"
 3) "completed"
 4) (nil)
 5) (nil)
 6) "1538225702,0793"
 7) (nil)
 8) "1538225699,2691"

Temporary solution for now is changing the indexJobs method on Laravel\Horizon\Repositories\RedisJobRepository (on line 195). I'm now forcing the failed_at, completed_at, and reserved_at to act as float instead of being a string:

protected function indexJobs($jobs, $indexFrom)
    {
        return $jobs->map(function ($job) use (&$indexFrom) {
            $job = (object) array_combine($this->keys, $job);
            if (!empty($job->failed_at)) {
                $job->failed_at = (float) str_replace(',', '.', (string) $job->failed_at);
            }
            if (!empty($job->completed_at)) {
                $job->completed_at = (float) str_replace(',', '.', (string) $job->completed_at);
            }
            if (!empty($job->reserved_at)) {
                $job->reserved_at = (float) str_replace(',', '.', (string) $job->reserved_at);
            }
            $job->index = $indexFrom;

            $indexFrom++;

            return $job;
        });
    }

Will have to look further why values are stored as strings.

[driesvints]

Hmm I can see how this can be a problem. Like you indicated @davidruigrok we'd probably need to cast the values to their proper types first. Not sure if your approach is the best one though.

Welcoming PRs for this.

[davidruigrok]

@driesvints, this was a dirty quick solution to get it working again. I will dive deeper into the code and create a better approach.

[philippe-tellier]

Any updates on this? I have the same problem.

[driesvints]

Can you all give me your PHP, Redis and Horizon versions where you're experiencing this problem?

[driesvints]

I believe I might have found the problem. It's probably the same problem as #123 so we might need to do this everywhere microtime is used. I'll send in a PR.

[driesvints]

Related: https://stackoverflow.com/questions/30052461/php-why-is-the-dot-in-a-decimal-replaced-by-comma-when-casted-to-string

[philippe-tellier]

Can you all give me your PHP, Redis and Horizon versions where you're experiencing this problem?

PHP: 7.2.11
Redis: 4.0.11
Horizon: 2.0.0

[iShotFT]

Can you all give me your PHP, Redis and Horizon versions where you're experiencing this problem?

PHP 7.2.12
redis_version:3.0.3
laravel/horizon: v1.4.3

[agustinprod]

@driesvints this is still happening if you use 'client' => 'phpredis' and you set a locale in your app service provider:

setlocale(LC_TIME, 'es_ES.utf8');

Maybe it's related to #788 . I'm not sure if is there anything to be fixed on the laravel end...But It works well with the old predis package.