[hydra] Enquêter sur la fréquence de crawl de certaines ressources non modifiées

[maudetes]

Il y a des exemples de ressources crawlées tous les jours quand bien même elles ne changent pas.

Par exemple, cette ressource dont la date de dernière modification est la même depuis 2025-06-02.

Pistes

1. Il s'agit d'une ressource moissonnée, dont la détection de modification se fait via la métadonnée harvest_modified_at en DB.
2. detected_last_modified_at n'est pas rempli à chaque fois dans le check apparemment :

hydra-hydra=> select created_at, detected_last_modified_at, next_check_at from checks where resource_id='51f43b0e-0c0a-4e26-802d-099c92237fea' order by created_at desc limit 30;
          created_at           | detected_last_modified_at |         next_check_at         
-------------------------------+---------------------------+-------------------------------
 2026-03-26 09:59:19.66375+01  | 2025-06-02 13:34:23+02    | 2026-03-26 23:00:43.202917+01
 2026-03-25 09:58:58.79402+01  | 2025-06-02 13:34:23+02    | 2026-03-27 18:03:01.272372+01
 2026-03-24 21:49:50.613426+01 | 2025-06-02 13:34:23+02    | 2026-03-27 12:15:47.233965+01
 2026-03-24 09:49:31.667101+01 |                           | 2026-03-24 21:49:31.665276+01
 2026-03-23 09:48:52.076539+01 | 2025-06-02 13:34:23+02    | 2026-03-24 09:48:52.075813+01
 2026-03-22 21:46:57.131644+01 | 2025-06-02 13:34:23+02    | 2026-03-23 09:47:00.738925+01
 2026-03-22 09:28:54.660618+01 |                           | 2026-03-22 21:28:54.659371+01
 2026-03-15 09:25:40.962614+01 | 2025-06-02 13:34:23+02    | 2026-03-22 09:25:40.961469+01
 2026-03-14 09:22:03.155941+01 | 2025-06-02 13:34:23+02    | 2026-03-15 09:22:03.153909+01
 2026-03-13 21:21:27.168271+01 | 2025-06-02 13:34:23+02    | 2026-03-14 09:21:31.178236+01
 2026-03-13 09:18:41.672842+01 |                           | 2026-03-13 21:18:41.665959+01
 2026-03-12 21:18:07.3616+01   | 2025-06-02 13:34:23+02    | 2026-03-13 09:18:10.985572+01
 2026-03-12 09:17:10.667508+01 |                           | 2026-03-12 21:17:10.665704+01
 2026-02-10 09:15:31.996792+01 | 2025-06-02 13:34:23+02    | 2026-03-12 09:15:31.995633+01
 2026-02-03 09:13:50.54324+01  | 2025-06-02 13:34:23+02    | 2026-02-10 09:13:50.541999+01
 2026-02-01 20:50:25.371683+01 | 2025-06-02 13:34:23+02    | 2026-02-03 09:11:08.258191+01
 2026-02-01 08:37:37.123381+01 |                           | 2026-02-01 20:37:37.121973+01
 2026-01-31 20:35:56.700192+01 | 2025-06-02 13:34:23+02    | 2026-02-01 08:36:05.252104+01
 2026-01-31 08:35:31.123692+01 |                           | 2026-01-31 20:35:31.122142+01
 2026-01-30 08:34:53.639138+01 | 2025-06-02 13:34:23+02    | 2026-01-31 08:34:53.637514+01
 2026-01-29 20:04:31.900053+01 | 2025-06-02 13:34:23+02    | 2026-01-30 08:34:21.31749+01
 2026-01-29 08:03:45.11962+01  |                           | 2026-01-29 20:03:45.118208+01
 2026-01-28 18:57:15.14563+01  | 2025-06-02 13:34:23+02    | 2026-01-29 06:57:18.688821+01
 2026-01-28 06:57:05.130972+01 |                           | 2026-01-28 18:57:05.121627+01
 2026-01-27 06:54:51.774682+01 | 2025-06-02 13:34:23+02    | 2026-01-28 06:54:51.772775+01
 2026-01-26 18:54:08.35111+01  | 2025-06-02 13:34:23+02    | 2026-01-27 06:54:11.809474+01
 2026-01-26 06:53:48.126232+01 |                           | 2026-01-26 18:53:48.124631+01
 2026-01-25 18:51:13.936244+01 | 2025-06-02 13:34:23+02    | 2026-01-26 06:51:41.563942+01
 2026-01-25 06:49:37.122641+01 |                           | 2026-01-25 18:49:37.121599+01
 2026-01-24 18:46:44.271838+01 | 2025-06-02 13:34:23+02    | 2026-01-25 06:46:46.12746+01

[bolinocroustibat]

Hypothèse pour expliquer des checks qui ont une valuer detected_last_modified_at en NULL alors que des checks précédents sur une même ressource ne l'étaient pas :

Il semble que le HEAD timeout parfois au crawl, alors une ligne checks est quand même créée (timeout = true, pas de checksum / mime), mais l’analyse n’est pas lancée. Du coup le check est créé avec detected_last_modified_at à NULL.

L’alternance NULL / rempli sur une même ressource semble correspondre à deux passages par jour : un qui timeout, l’autre qui réussit.

Par exemple, sur fd968e61-5547-4797-96db-9488f3f2ca8b :

Les checks avec detected_last_modified_at NULL sont des lignes avec timeout = true, pas de status, pas de headers, pas de checksum / mime.
Le même jour, un autre check (souvent le soir) a timeout = false, status = 200, checksum + text/html + detected_last_modified_at rempli, donc là l’analyse a bien tourné.

Requête pour confirmer :

COUNT(*) FILTER (WHERE timeout AND detected_last_modified_at IS NULL)  -- 39
COUNT(*) FILTER (WHERE NOT timeout AND detected_last_modified_at IS NULL AND checksum IS NOT NULL)  -- 0

Pour cette ressource sur la fenêtre demandée : tous les NULL qu’on compte dans ce découpage viennent du timeout, et aucun ne semble avoir une analyse allée au bout (checksum présent) mais detected_last_modified_at vide.

Requête des checks récents avec detected_last_modified_at= NULL en montrant timeout, absence de status / checksum / mime :

SELECT id, created_at,
       detected_last_modified_at,
       status, timeout, error,
       headers IS NOT NULL AS has_headers,
       checksum IS NOT NULL AS has_checksum,
       mime_type
FROM checks
WHERE resource_id = 'fd968e61-5547-4797-96db-9488f3f2ca8b'
  AND detected_last_modified_at IS NULL
  AND created_at >= timestamptz '2026-01-01 00:00:00+01'
ORDER BY created_at DESC
LIMIT 15;

Même requête mais avec alternance : passage timeout (NULL / vide) puis passage OK (200, checksum, detected_last_modified_at) :

SELECT id, created_at,
       status, timeout,
       checksum IS NOT NULL AS has_checksum,
       mime_type,
       detected_last_modified_at IS NOT NULL AS has_detected
FROM checks
WHERE resource_id = 'fd968e61-5547-4797-96db-9488f3f2ca8b'
  AND created_at >= timestamptz '2026-03-17 00:00:00+01'
  AND created_at <  timestamptz '2026-03-20 00:00:00+01'
ORDER BY created_at;

Zoom sur des id précis pour confirmer timeout = true, pas de headers :

SELECT id, created_at, status, timeout, error,
       headers IS NOT NULL AS has_headers,
       checksum, mime_type, detected_last_modified_at
FROM checks
WHERE id IN (43722464, 43813142, 43885541);

[bolinocroustibat]

On a related subject: #413