Skip to content

fix(cron): unblock #55 + #56, and make cron-failure alert show log tail#63

Draft
SALL911 wants to merge 2 commits into
mainfrom
claude/check-current-status-U6zQi
Draft

fix(cron): unblock #55 + #56, and make cron-failure alert show log tail#63
SALL911 wants to merge 2 commits into
mainfrom
claude/check-current-status-U6zQi

Conversation

@SALL911
Copy link
Copy Markdown
Owner

@SALL911 SALL911 commented May 18, 2026

Summary

3 commits, two fronts:

1. 高信心修兩條 cron — #55 + #56

靠程式碼推回兩個 90%+ 信心的 bug(沒 Actions log 存取):

  • 🚨 [cron-failure] GEO Audit Queue (prospects) #55 GEO Audit Queuefetch_prospects()datetime.now(timezone.utc).isoformat()(含 +00:00 時區後綴)直接塞進 PostgREST query string。+ 在 query string 規範下解碼成空格,PostgREST 收到的就是 2026-05-...123456 00:00,timestamp 解析失敗 → 400 → 整支腳本從第一步就 raise。改用 urllib.parse.quote(..., safe="") 包住 cutoff。
  • 🚨 [cron-failure] Composio — Lead → HubSpot sync #56 Composio Lead → HubSpot — HubSpot 不收 null 屬性、且對既存 email 回 409。兩個都讓整批 sync 被一筆爛資料拖垮。改成「空字串屬性過濾掉」+「409 / already exists / CONTACT_EXISTS 視為冪等成功、mark synced」。

故意沒動:Composio v3 endpoint 路徑 /api/v3/actions/{name}/execute。沒 log 我不敢猜 v3 是不是改了路徑。

2. 改造 cron-failure-alert,讓下次失敗自帶 log

剩 4 條(#57 Figma / #59 BCI / #60 Quota / #61 Notion)我沒把握靠肉眼推。改告警 workflow 比改 4 支腳本安全。

新版 cron-failure-alert.yml

  • 透過 Actions API 抓失敗 job 的 plain-text log
  • 去時間戳前綴、取最後 80 行
  • 嵌進 issue 留言的 <details> 區塊
  • 用 base64 過 GITHUB_OUTPUT 避免多行 quoting 問題
  • 整個步驟 set +e + fallback 空字串,告警自己絕不能變紅

下一輪 cron 失敗,所有 issue 都會自帶錯誤摘要,剩 4 條的根因就會浮出來。

Test plan

#55 GEO Audit Queue (prospects)
- fetch_prospects() was URL-embedding an ISO timestamp with a "+00:00"
  timezone suffix into the PostgREST query string. The "+" is decoded as
  a space per the form-encoding spec, so PostgREST received a malformed
  timestamp and 400'd every run. Wrap the cutoff with urllib.parse.quote
  (safe="") so the offset survives transit.

#56 Composio Lead -> HubSpot sync
- HubSpot rejects null-valued firstname/lastname/company properties and
  returns 409 on duplicate email. Both were treated as hard failures, so
  one already-synced lead in the queue burned the entire run. Now we
  strip empty-string properties before sending and treat the
  "already exists / 409 / duplicate" surface as an idempotent success
  (still marks the row synced so we stop re-trying).

Both fixes are narrow and based on script inspection (no Actions log
access from this environment). If next hour's cron still red, the
remaining suspect is the Composio v3 actions/{name}/execute path, which
we haven't touched.
@vercel
Copy link
Copy Markdown

vercel Bot commented May 18, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
brandos-orchestrator Ready Ready Preview, Comment May 18, 2026 7:19am
symcio-landing Ready Ready Preview, Comment May 18, 2026 7:19am

So far the bot just dropped a run URL into the issue. With #55/#56 still
red for ~14 days and no log-fetch tool available outside the workflow
itself, we were guessing at root causes. This step:

1. Lists jobs of the failed workflow_run, picks the first failure.
2. Downloads that job's plain-text log via the Actions API.
3. Strips the timestamp prefix and grabs the last 80 lines.
4. Embeds it in a <details> block on the alert issue (initial body and
   each "failed again" follow-up comment).

actions: read added to permissions; base64 piped through GITHUB_OUTPUT so
multi-line log content survives intact. Step is wrapped in set +e and
falls back to empty if log fetch fails — alert workflow must never go
red itself.
@SALL911 SALL911 changed the title fix(cron): unblock #55 geo-audit-queue + #56 composio-hubspot-sync fix(cron): unblock #55 + #56, and make cron-failure alert show log tail May 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants