SPB Git

spb/job-ka

Public
page 1
  1. Tue, Oct 27, 2026 4

    1. [ka6] connecteur microhabitat: stale = fermeture saisonnière EN BLOC des 13 offres le 2026-10-27, rien à réparer dans le fetch — purge accélérée des offres fantômes. Chronologie : vert found=13 en continu jusqu'à 17:26 EDT, puis ok=1 found=0 dès 20:42 — les 13 postes (saisonniers d'agriculture urbaine parus au printemps, ex. Urban Farming Coordinator du 2026-04-29) fermés d'un coup entre les deux, fin de saison. Vérification live : /json 200 `[]` (contrôle décisif : une org Breezy inexistante renvoie 404 — le tenant est VIVANT), les 13 pages /p/ sondées une à une affichent toutes « Position Closed — Sorry, this position is no longer accepting candidates » sans formulaire de candidature, et microhabitat.com/careers pointe toujours vers microhabitat.breezy.hr — zéro migration, le volume 0 est CORRECT. Particularité vs les faux positifs « volume QC nul » habituels : médiane 13 ≥ DRIFT_MIN_BASE 8 → le garde-fou de dérive suspendait les retraits et laissait 13 offres fantômes actives en ligne. Purge par le mécanisme normal accéléré (précédent vadesk) : 3 syncs isolés rejoués → la médiane de la fenêtre DRIFT_HISTORY=5 tombe à 0, le garde se lève, règle des 2 absences → removed=13, 0 offre active en base = reflet exact de la source. Dernier sync vert ok=1 found=0 en 1,8 s. Aucun code de fetch modifié, docstring chronologie seulement ; le connecteur reverdira seul à la prochaine saison d'embauche. Fiches microhabitat.md/ats-breezy.md/INDEX.md régénérées (1133 autres restaurées, hors périmètre). 108 tests pytest verts, pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 4 files +200 −211
    2. [ka6] fix connecteur ingeniuinc: migration d'ATS SmartRecruiters → site Odoo de l'employeur le 2026-10-27 — tenant SR vidé, nouvelle plateforme odoo.py. Diagnostic : vert found=1 en continu jusqu'à 07:32 EDT, puis ok=1 found=0 dès 10:23 (removed=1 à la règle des 2 absences) — l'unique offre, un fantôme paru le 2021-08-02, dépubliée entre les deux. Vérification live : API postings SmartRecruiters IngeniuInc 200 totalFound=0 (tenant existant mais vidé), page board 404 ; l'entreprise s'est rebaptisée Ingeniu Solutions (ingeniu.ca → www.ingeniusolutions.com) et publie désormais sur son PROPRE site Odoo (module website_hr_recruitment, /jobs) : 2 offres publiées. Nouvelle classe de plateforme jobka/connectors/odoo.py (pattern glow) : liste HTML rendue serveur (cartes jobs_grid, ancre /jobs/<slug>-<id>, titre <h3>, libellé <address>), pagination /jobs/page/N suivie, détail par MICRODONNÉES schema.org/JobPosting (meta datePosted/employmentType, div itemprop=description) — ⚠️ la div description ne porte que l'intro, le corps (responsabilités, compétences, avantages) vit dans les blocs website-builder qui la suivent : capture jusqu'au footer, CTA retiré ; cache BD + budget de re-visites (JOBKA_ODOO_DETAIL_LIMIT=60), garde-fou anti faux « 0 offre » (marqueur jobs_grid + retry). Lieux en cascade (doctrine bento_sushi, rien d'inventé) : addressLocality structurée → libellé <address> QC → ville citée dans le bloc JobPosting (« à notre bureau de Montréal », « Située à Montréal ») validée contre le référentiel des municipalités QC ; tout ce qui suit <footer> (siège en pied de page) jamais lu. ingeniuinc.py re-pointé sur OdooConnector (ids 743999764601957 → 15/38), sources.json mis à jour (url, careers_url, connector=odoo). Tests réels : fetch isolé 2 offres Montréal (teletravail/hybride, temps_plein, descriptions 2623/3633 car.), sync vert ok=1 found=2 added=2 en 0,3 s (médiane 0.5 — le nouveau board porte réellement 2 offres), 2 offres actives en base, l'ancienne offre SR inactive. 108 tests pytest verts, pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200. Fiches ingeniuinc.md/ats-odoo.md/ats-smartrecruiters.md/INDEX.md régénérées (1132 autres restaurées, hors périmètre).
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 7 files +545 −243
    3. [ka6] fix connecteur groupepmi: migration d'ATS Zoho Recruit → Glow in the Cloud le 2026-10-27 — tenant Zoho RÉSILIÉ, nouvelle plateforme glow.py. Diagnostic : vert found=10 en continu jusqu'à 07:20 EDT, puis ok=1 found=0 dès 10:10 (retraits suspendus par le garde-fou de dérive) ; le RSS et /jobs/Careers de groupepmi.zohorecruit.com renvoient tous deux une page d'erreur Zoho « groupepmi.zohorecruit.com does not exist » (200, 2596 octets) — tenant supprimé chez Zoho, pas un blip. La page carrières officielle groupepmi.ca/carriere/ pointe désormais (4 liens) vers jobs.glowinthecloud.com/groupepmi : ATS québécois Glow in the Cloud, 10 offres publiées (= médiane historique). Nouvelle classe de plateforme jobka/connectors/glow.py (pattern JazzHR) : liste HTML rendue serveur (cartes avec adresse complète), détail JSON-LD JobPosting (tabulations littérales absorbées par _jsonld), cache BD + budget de re-visites, garde-fou anti faux « 0 offre » (marqueur jobSearch-result + retry). Lieux en cascade (doctrine bento_sushi, rien d'inventé) : adresse de liste → jobLocation JSON-LD → ville citée dans la description validée contre le référentiel des municipalités QC (« Chantier Joliette ») ; le <address> des pages détail est le SIÈGE en footer, jamais utilisé ; 1 offre sans aucun marqueur de lieu correctement écartée. groupepmi.py re-pointé sur GlowConnector (ids 717696… → 20261015002…), sources.json mis à jour (careers_url, connector=glow). Tests réels : fetch isolé 9 offres QC/10 publiées, 2 syncs verts ok=1 found=9 (médiane 10) en 1,1 s puis 1,7 s avec removed=10 (anciennes offres Zoho retirées à la règle des 2 absences), 9 offres actives en base. 108 tests pytest verts, pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200. Fiches groupepmi.md/ats-glow.md/ats-zoho_recruit.md/INDEX.md régénérées (1131 autres restaurées, hors périmètre).
      Simon-Pierre Boucher · 7 files +576 −282
  2. Mon, Oct 26, 2026 6

    1. [ka6] connecteur dentons: broken = faux positif « volume QC nul », rien à réparer — les 2 offres QC du portail SuccessFactors ont été dépubliées le 2026-10-26. Profil connu « ok=1 found=0 médiane ≤1 » (70+ cas) : la supervision compte un sync à 0 offre comme non-succès. Chronologie : vert found=2 en continu jusqu'à 14:37 EDT, puis ok=1 found=0 dès 17:14 — la paire FR/EN « Responsable, Comptes fournisseurs / Accounts Payable Lead » Montréal (ids 1362980357/1362877757, parue 2026-10-04) dépubliée entre les deux, probablement poste comblé. Vérification live : sitemap urlset careers.dentons.com 200 avec 131 offres mondiales mais zéro slug QC, pages détail des 2 ids retombées sur le gabarit CSB vide (titre présent mais AUCUNE microdonnée itemprop — contrôle décisif : l'offre vivante Rome-Associate-Litigation du sitemap a itemprop description/datePosted/title) — tenant VIVANT, zéro migration, le volume 0 est CORRECT. Les offres avaient déjà été retirées proprement à la règle des 2 absences (removed=2 à 18:09). Sync isolé rejoué : vert ok=1 found=0 en 0,4 s, 0 offre active en base = reflet exact de la source. Aucun code de fetch modifié, docstring chronologie seulement ; le connecteur reverdira seul à la prochaine publication QC (le bureau de Montréal publie bien ici, cf. docstring). Fiches dentons.md/ats-successfactors.md/INDEX.md régénérées (1131 autres restaurées, hors périmètre). 108 tests pytest verts, pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 4 files +43 −57
    2. [ka6] fix connecteur mitsubishi_hc_capital: 3e tenant ADP WFN touché le 2026-10-26 par le frontal intermittent par cid — même panne que bento_sushi (64f53c8f) et cookit (7873198d), même garde-fou de retry borné scoped au connecteur. Diagnostic : vert found=1 en continu jusqu'à 11:15 EDT, puis 404 franc sur la liste job-requisitions à 15:25 pendant que les frères ADP (cookit, bento_sushi, cultures_genv, groupe_nordik, h2o_innovation, ciena, richelieu…) sont verts à la même heure — pool backend malade côté ADP sélectionné par cid ; un seul raté suffit à rendre la source stale (cycle ~3 h > seuil 4 h) et le repli « détail seulement » de 9d9e3f4e laisse volontairement passer les 4xx. Sonde live de 8 essais à ~17h45 : 8× 200 JSON complet (meta.totalNumber=1 = médiane 1.0, requisitionLocations intactes 3/3 QC : pas besoin du fallback d'adresse de bento_sushi) — frontal malade par intermittence seulement. Correctif minimal dans mitsubishi_hc_capital.py : _get_json retente jusqu'à 30 fois (pause 2 s) sur 404/502/503/504/timeout/non-JSON, timeout abaissé 30→15 s pour borner les connexions qui pendent ; dormant dès que le frontal est sain (1er essai OK = zéro surcoût), un sync vert ne coûte qu'UN appel liste (détails en cache BD) ; compose avec le repli détail existant (un 404 persistant après 30 essais reste un échec propre, inventaire préservé). Tests réels : sync isolé vert ok=1 found=1 (= médiane 1.0) en 1,1 s, 1 offre active en base, 0 retrait ; chemin de retry prouvé par simulation (2× 404 absorbés puis 1 offre live). 108 tests pytest verts, pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200. Fiches mitsubishi_hc_capital.md/ats-adp.md/INDEX.md régénérées (1131 autres restaurées, hors périmètre).
      Simon-Pierre Boucher · 4 files +253 −204
    3. Simon-Pierre Boucher · 4 files +119 −68
    4. [ka6] fix connecteur bento_sushi: le frontal ADP WFN ne sert plus ce tenant que par intermittence depuis ~08h EDT le 2026-10-26 (~1 requête sur 8 aboutit, sinon 404 nginx/openresty de 150 octets ou connexion qui pend) — garde-fou de retry borné scoped au connecteur. Diagnostic : vert found=8 en continu jusqu'à 07:23, puis 404 à 10:06 et 12:52 ; PAS systémique (les 15 autres tenants ADP verts à la même minute, ex. cultures_genv ok à 13:09:41 pendant que cookit échoue à 13:09:10 — seul cookit partage la signature), PAS notre IP (identique via proxy résidentiel Oxylabs -cc-CA), PAS le ccId (des verts partagent le défaut 19000101_000001), PAS une migration (portail humain recruitment.html 200, bentosushi.com/careers référence toujours le cid d0dfb14c, et l'essai chanceux 200 rend le JSON complet meta.totalNumber=8 = médiane) : pool backend malade côté ADP, sélectionné par cid, IP edge unique 170.146.102.193 donc rien à épingler. Correctif minimal dans bento_sushi.py : _get_json retente jusqu'à 30 fois (pause 2 s) sur 404/502/503/504/timeout/non-JSON, timeout abaissé à 30→15 s pour borner les connexions qui pendent (la voie directe et l'escalade proxy héritée de la base en profitent, coupe-circuit par hôte en aval) ; dormant dès que le frontal redevient sain (1er essai OK = zéro surcoût) et un sync vert ne coûte qu'UN appel liste (détails en cache BD). Le fix locations-absentes du 2026-10-23 (e0743907) reste nécessaire et actif (requisitionLocations toujours vides dans le 200 obtenu). Tests réels : 3 syncs isolés verts ok=1 found=8 (= médiane 8.0) en 1,7 s / 43,5 s / 53,3 s (le retry mâche les rafales de 404 : une rafale de 15 échecs consécutifs observée, d'où 30 essais, P(échec)≈2 %), 1 échec propre à 15 essais pendant le calibrage (erreur propagée, 8 offres actives intactes, 0 retrait). cookit = même panne, hors périmètre de cette mission. 108 tests pytest verts, pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200. Fiches bento_sushi.md/ats-adp.md/INDEX.md régénérées (1131 autres restaurées, hors périmètre).
      Simon-Pierre Boucher · 4 files +236 −183
  3. Sat, Oct 24, 2026 22

    1. Simon-Pierre Boucher · 4 files +25 −44
    2. Revert "[ka6] connecteur ville_mirabel: stale = faux positif, maintenance planifiée Njoyn en cours — rien à réparer. Même fenêtre systémique que cgi (ecb31c08), cusm_ir (d6a7c87f), groupe_bellemare (f388cbcc), groupe_master (58a30264), rtc_quebec (7cbdaeb7), rtl (26bdd8bb), sante_montreal (c3b7b032), stl_laval (f17ee419) et ville_gatineau (72ed45ce), récidive du 2026-09-05→07, vendredi soir → dimanche ~21h EDT : ville_mirabel vert found=3 (médiane 3.0) jusqu'à 19:10 EDT le 2026-10-23, puis « maintenance planifiée (redirection maintenance.njoyn.com) » à 21:36, comme les 11 tenants Njoyn de l'app. Le « volume 0 » vu par la supervision est l'entrée du sync avorté, pas une chute réelle. Vérification live 2026-10-24 ~01h30 EDT : le sync isolé rejoué via la vraie voie Scrapfly (USE_SCRAPFLY=True, clients.njoyn.com CL4/71754) avorte explicitement en ~3 s avec le message maintenance. Le garde-fou _MAINT_RE fonctionne comme prévu : sync avorté proprement, 3 offres actives conservées en base (0 retrait ville_mirabel ; les 26 offres retirées pendant le test sont des dates limites échues d'autres sources, cycle normal). Le tenant reverdira seul à sa rotation horaire au retour du service (~dimanche 21h). Aucun code de fetch modifié, docstring chronologie seulement ; fiches ville_mirabel.md/ats-njoyn.md/INDEX.md régénérées (1131 autres fiches restaurées, hors périmètre). 108 tests verts, pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200."
      …
      This reverts commit c43a14c07459930d6302a6621793e2f976162476.
      Simon-Pierre Boucher · 4 files +29 −48
    3. Revert "[ka6] connecteur ville_terrebonne: stale = faux positif, maintenance planifiée Njoyn en cours — rien à réparer. Même fenêtre systémique que cgi (ecb31c08), cusm_ir (d6a7c87f), groupe_bellemare (f388cbcc), groupe_master (58a30264), rtc_quebec (7cbdaeb7), rtl (26bdd8bb), sante_montreal (c3b7b032), stl_laval (f17ee419), ville_gatineau (72ed45ce) et ville_mirabel (c43a14c0), récidive du 2026-09-05→07, vendredi soir → dimanche ~21h EDT : ville_terrebonne vert found=11 (médiane 11.0) jusqu'à 19:10 EDT le 2026-10-23, puis « maintenance planifiée (redirection maintenance.njoyn.com) » à 21:36, comme les 11 tenants Njoyn de l'app. Le « volume 0 » vu par la supervision est l'entrée du sync avorté, pas une chute réelle. Vérification live 2026-10-24 ~01h45 EDT : le sync isolé rejoué via la vraie voie Scrapfly (USE_SCRAPFLY=True, clients.njoyn.com CL4/71764) avorte explicitement en ~4 s avec le message maintenance. Le garde-fou _MAINT_RE fonctionne comme prévu : sync avorté proprement, 11 offres actives conservées en base (0 retrait ville_terrebonne ; les offres retirées pendant le test sont des dates limites échues d'altitudeaerospace/chu_quebec/cssdm, cycle normal). Le tenant reverdira seul à sa rotation horaire au retour du service (~dimanche 21h). Aucun code de fetch modifié, docstring chronologie seulement ; fiches ville_terrebonne.md/ats-njoyn.md/INDEX.md régénérées (1131 autres fiches restaurées, hors périmètre). 108 tests verts, pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200."
      …
      This reverts commit ec1394032d2455addfa0f688d10ff919ae6df866.
      Simon-Pierre Boucher · 4 files +25 −44
    4. [ka6] connecteur ville_terrebonne: stale = faux positif, maintenance planifiée Njoyn en cours — rien à réparer. Même fenêtre systémique que cgi (ecb31c08), cusm_ir (d6a7c87f), groupe_bellemare (f388cbcc), groupe_master (58a30264), rtc_quebec (7cbdaeb7), rtl (26bdd8bb), sante_montreal (c3b7b032), stl_laval (f17ee419), ville_gatineau (72ed45ce) et ville_mirabel (c43a14c0), récidive du 2026-09-05→07, vendredi soir → dimanche ~21h EDT : ville_terrebonne vert found=11 (médiane 11.0) jusqu'à 19:10 EDT le 2026-10-23, puis « maintenance planifiée (redirection maintenance.njoyn.com) » à 21:36, comme les 11 tenants Njoyn de l'app. Le « volume 0 » vu par la supervision est l'entrée du sync avorté, pas une chute réelle. Vérification live 2026-10-24 ~01h45 EDT : le sync isolé rejoué via la vraie voie Scrapfly (USE_SCRAPFLY=True, clients.njoyn.com CL4/71764) avorte explicitement en ~4 s avec le message maintenance. Le garde-fou _MAINT_RE fonctionne comme prévu : sync avorté proprement, 11 offres actives conservées en base (0 retrait ville_terrebonne ; les offres retirées pendant le test sont des dates limites échues d'altitudeaerospace/chu_quebec/cssdm, cycle normal). Le tenant reverdira seul à sa rotation horaire au retour du service (~dimanche 21h). Aucun code de fetch modifié, docstring chronologie seulement ; fiches ville_terrebonne.md/ats-njoyn.md/INDEX.md régénérées (1131 autres fiches restaurées, hors périmètre). 108 tests verts, pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 4 files +44 −25
    5. [ka6] connecteur ville_mirabel: stale = faux positif, maintenance planifiée Njoyn en cours — rien à réparer. Même fenêtre systémique que cgi (ecb31c08), cusm_ir (d6a7c87f), groupe_bellemare (f388cbcc), groupe_master (58a30264), rtc_quebec (7cbdaeb7), rtl (26bdd8bb), sante_montreal (c3b7b032), stl_laval (f17ee419) et ville_gatineau (72ed45ce), récidive du 2026-09-05→07, vendredi soir → dimanche ~21h EDT : ville_mirabel vert found=3 (médiane 3.0) jusqu'à 19:10 EDT le 2026-10-23, puis « maintenance planifiée (redirection maintenance.njoyn.com) » à 21:36, comme les 11 tenants Njoyn de l'app. Le « volume 0 » vu par la supervision est l'entrée du sync avorté, pas une chute réelle. Vérification live 2026-10-24 ~01h30 EDT : le sync isolé rejoué via la vraie voie Scrapfly (USE_SCRAPFLY=True, clients.njoyn.com CL4/71754) avorte explicitement en ~3 s avec le message maintenance. Le garde-fou _MAINT_RE fonctionne comme prévu : sync avorté proprement, 3 offres actives conservées en base (0 retrait ville_mirabel ; les 26 offres retirées pendant le test sont des dates limites échues d'autres sources, cycle normal). Le tenant reverdira seul à sa rotation horaire au retour du service (~dimanche 21h). Aucun code de fetch modifié, docstring chronologie seulement ; fiches ville_mirabel.md/ats-njoyn.md/INDEX.md régénérées (1131 autres fiches restaurées, hors périmètre). 108 tests verts, pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200.
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 4 files +48 −29
  4. Fri, Oct 23, 2026 8

    1. [ka6] fix connecteur h2o_innovation: le babillard fr_CA du tenant ADP WFN a cessé d'exposer requisitionLocations (liste+détail, 0/11) entre 00:06 et 02:35 EDT le 2026-10-23 — même nuit et même mécanique que bento_sushi (e0743907) — le filtre Québec rejetait les 10 offres pourtant toujours publiées (mêmes itemID). Particularité H2O vs bento: le babillard en_US du MÊME tenant expose encore ses locations (19/19) mais ne partage que ~3 itemID avec fr_CA, et les descriptions ne publient pas d'adresse complète (seulement « usine située à Ham-Nord », « bureau de Québec »). Correctif scoped au connecteur (_keep + _resolve_blind): une réquisition sans location passe le filtre puis son lieu est résolu sans rien inventer — 1) offre active connue en base = ville/code postal qu'ADP exposait avant la panne (offre revalidée live par la liste), 2) jointure par itemID sur le babillard en_US (locations ADP live; hors-QC écartée — cas réel « L'ingénieur.e de procédés » Burlington ON), 3) ville citée dans la description de l'employeur validée par region_for_city. Une offre sans marqueur QC est écartée; chemin normal repris tel quel si ADP ré-expose les locations fr_CA (fallback dormant). Sync isolé rejoué: ok=1 found=10 (= médiane 10.0) en 20,8 s, 10 actives avec ville/postal/région/GPS 100 %. 108 tests verts, pm2 restart job-ka-sync OK, site local 200, www.job-ka.com 200. Fiches h2o_innovation.md/ats-adp.md/INDEX.md régénérées (1131 autres fiches restaurées, hors périmètre).
      …
      Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
      Simon-Pierre Boucher · 4 files +138 −20
Menu

Theme