[Bug] /api/v1/videos/:id returns 200 with no content, throws exception in logs

[Drikanis]

Describe the bug

The invidious plugin for Kodi stopped working for me, after investigating it looks like one of the API endpoints is no longer functional, at least for some videos.

Steps to Reproduce
Steps to reproduce the behavior:

1. Fetch /api/v1/videos/wIp8vQxDS-M
2. 200 code returned with no content
3. Exception in server logs

Logs

Client:

$ http get https://invidious.lab/api/v1/videos/wIp8vQxDS-M
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 20
Content-Security-Policy: default-src 'none'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self' data:; connect-src 'self'; manifest-src 'self'; media-src 'self' blob: https://*.googlevideo.com:443 https://*.youtube.com:443; child-src 'self' blob:; frame-src 'self'; frame-ancestors 'none'
Content-Type: application/json
Date: Wed, 29 Jan 2025 00:33:55 GMT
Permissions-Policy: interest-cohort=()
Referrer-Policy: same-origin
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: sameorigin
X-XSS-Protection: 1; mode=block

Server:

2025-01-29 00:33:16 UTC [info] 200 GET /api/v1/videos/wIp8vQxDS-M 1971.16ms
Exception: Invalid number at 0: ">>" (Time::Format::Error)
  from /usr/share/crystal/src/time/format/parser.cr:597:90 in 'raise'
  from /usr/share/crystal/src/time/format/parser.cr:594:5 in 'raise'
  from /usr/share/crystal/src/time/format/pattern.cr:199:7 in 'year_month_day'
  from /usr/share/crystal/src/time/format/parser.cr:505:14 in 'parse_rfc3339'
  from src/invidious/jsonify/api_v1/video_json.cr:272:76 in 'video:locale:proxy'
  from src/invidious/routes/api/v1/videos.cr:22:7 in '->'
  from src/invidious/helpers/handlers.cr:31:37 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call_next'
  from lib/kemal/src/kemal/filter_handler.cr:21:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call_next'
  from src/invidious/helpers/handlers.cr:95:12 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call_next'
  from src/ext/kemal_static_file_handler.cr:106:14 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call'
  from /usr/share/crystal/src/http/server/handler.cr:30:7 in 'call'
  from /usr/share/crystal/src/http/server/request_processor.cr:51:11 in 'handle_client'
  from /usr/share/crystal/src/fiber.cr:143:11 in 'run'
  from ???

Screenshots

Additional context

Invidious running on quay.io/invidious/invidious:2025.01.22-164d764

[ChilliGeologist]

Also experiencing this exact issue after switching from the latest to the master branch

[Drikanis]

The cause seems to be 164d764#diff-44ad5a0fea31152bcad7d3a779935ca234c0a4f657772d835b27b3a084e61b90R271

"published" on a related video can be a valid date or an empty string, but it tries to parse it as long as it's not nil. I assume this is leading it to parse an empty string, and thus fail.

[lamarios]

There are two issues i believe, one is the recommended videos "published" is a formatted date instead of a timestamp but also some videos return empty content

Edit:

Updated server ( 2025.01.26-00ee3814 @ master)

❯ curl https://your-server/api/v1/videos/TuM-s-2qnI0          
# empty response

Outdated server ( 2024.11.10-5d2dd40 @ (HEAD detached at v2.20241110.0) ) :

❯ curl https://my-server/api/v1/videos/TuM-s-2qnI0
{"type":"video","title":"Can We Beat Dustin & Austin Johnson in a Golf Match?... <full json> }

[Drikanis]

some videos return empty content

Yeah the empty content is due to this issue, and my PR fixes that.

the recommended videos "published" is a formatted date instead of a timestamp

If the format of the related videos "published" field isn't what is expected/intended then that sounds like a separate problem? It appears to be specifically implemented to return a formatted date, so I assumed it was intentional.