Log channel 與 error code 索引

目的

這份索引用 Slack / application log channel / API error code 反查排查入口。

它不重寫完整 business flow,也不記錄單次測試 ID。完整流程請回到業務流程、付款流程、log 與告警流程或 專案 migration detail。

文件狀態:草稿 / 收錄近期排查常用項目
最後驗證:2026-05-07
來源:Common Process Documents、專案 migration detail、new API code grep

使用方式

排查時先判斷你手上的是哪種線索:

線索優先看
Slack channel本文件的 Log channel 區
API response error本文件的 Error code 區
response status 是翻譯文字先找 message key,再看 Error code 區
付款 / contact 失敗先看 processWantToContactProviderlogQuoteBidTxn
route / endpoint 不確定API Endpoint 索引../API 路由與遷移/README

涉及 pro360_api_82 DB 查詢時,遵守 repo 規則:容器 PHP 8.2 + DBFactory,先查 schema,再查資料。

Log channel

Channel出現位置代表什麼優先查
processWantToContactProviderLib/Model/QuoteBid.php::processWantToContactProvider()quote bid 正式 contact / charge 主線失敗或關鍵狀態../付款與扣款流程/quote_bid_contact_chargequote_bidstransactions
logQuoteBidTxnLib/Model/Transaction.php::logQuoteBidTxn()transaction 寫入前被擋或金額異常../資料表流程/transactions/READMEtransactions
getCheckConnectLib/Util/RedisUtil.php::getCheckConnect()Redis 連線失敗後重連或仍不可用../設定與環境來源/類型/Redis、付款 lock / cache 使用點
FPSEndpoint/V1/PayBank.php::hsbc()FPS / HSBC callback 或解密資訊../Log 與告警流程/README、付款 callback 相關 table
QUERY_ERRORDB statement error handlerSQL 執行錯誤../Log 與告警流程/README、錯誤 SQL 對應 model
DB_modifyDB update / modify exceptionDB 修改時發生 exception../Log 與告警流程/README、相關主 table
GLOBALnew API error handlerPHP error handler 捕捉到的錯誤../Log 與告警流程/README、request route
Exception_<code>Lib/Exception/PRO360Exception.php建立 PRO360Exception 且指定送 Slackresponse error code、message key、對應 endpoint
Uncaught Exceptionlegacy app/Config/core.php::fatalErrorHandler()legacy fatal error shutdown handler../Log 與告警流程/README、legacy request/controller

processWantToContactProvider

這是 quote bid contact / narrow accept 最重要的排查入口之一。

常見情境:

  • provider 無法聯繫。
  • provider 資格 / phone / block guard 被擋。
  • wallet / card / TapPay prime 付款失敗。
  • contact state 沒有成立。

排查順序:

application log channel = processWantToContactProvider
-> quote_bids
-> quote_requests
-> transactions
-> event_queue / event_queue_log_1..event_queue_log_4
-> task_event_queue / task_event_queue_log

常見誤判:

  • API response error=10 只代表外部錯誤碼;內部原因要看 log context。
  • 沒有 transaction 不一定是 transaction bug,可能是進 transaction 前就被 guard / payment 擋掉。

logQuoteBidTxn

這個 channel 通常代表已經走到 transaction 寫入前後。

常見情境:

  • amount < 0
  • amount: 0
  • transaction 欄位或餘額不合理

先看 log message / context,再回查:

transactions
quote_bids.quote_user_subscription_log_id
provider wallet / balance

getCheckConnect

這個 channel 通常代表 Redis connection 檢查失敗後嘗試重連。

若同時在排查 quote bid contact / payment,要分清楚:

Redis lock 問題
!= payment provider 失敗
!= transaction 寫入失敗

先看 ../設定與環境來源/類型/Redis,再回到 ../付款與扣款流程/quote_bid_contact_charge../資料表流程/transactions/README

Error code:provider_accept_narrow_match

Endpoint:

POST /quote_bids/provider_accept_narrow_match/<quote_bid_id>.json
POST /quote_bids/provider_accept_narrow_match/<quote_bid_id>/narrow_status_id:<status>.json

主要入口:

Response errorMessage key意義優先查
1err_provider_accept_narrow_match_1request invalid / session invalid / generic guardendpoint params、session、provider actor
2err_provider_accept_narrow_match_1找不到 bidquote_bids
3err_provider_accept_narrow_match_1呼叫者不是 providersession user、quote_bids.provider_user_id
4err_provider_accept_narrow_match_4request 已封存 / 關閉 / 過期 / 已 hiredquote_requests 狀態欄位
5err_provider_accept_narrow_match_1bid 不是 narrow matchquote_bids.is_narrow_match
6err_provider_accept_narrow_match_6bid 已聯繫扣款quote_bids.is_want_to_contact_provider、transaction
7err_provider_accept_narrow_match_1bid 不在 waiting narrow matchquote_bids.narrow_status_id
690err_provider_accept_narrow_match_690provider 接案資格限制 / 目前無法聯繫processWantToContactProvider log、provider qualification
251err_provider_accept_narrow_match_251provider 尚未完成接案資格provider certification / qualification
256err_provider_accept_narrow_match_256provider 封鎖 consumerblock / chat restriction
211err_provider_accept_narrow_match_211外國卡 / 不支援卡片processWantToContactProvider log、TapPay / card result
10err_provider_accept_narrow_match_10未設定信用卡 / charge errorprocessWantToContactProvider log、transactions 是否未建立

error 10

常見 response:

{
  "error": 10,
  "status": "請先設定信用卡以進行報價",
  "bank_result_code": null,
  "bank_result_msg": null
}

這通常代表 provider accept 時進入 contact charge,但 wallet / card / prime 不足以完成付款。

先查:

channel = processWantToContactProvider

再確認:

quote_bids.narrow_status_id 不應變 ACCEPTED
quote_bids.is_want_to_contact_provider 不應變 1
transactions 不應建立成功交易
quote_activities 不應出現 accept/contact 成功 activity

error 211

通常是 card / TapPay provider 回傳外國卡或不支援卡片類錯誤。外部 response error 是 211,但仍應以 application log context 判斷實際 payment provider result。

error 690 / 251 / 256

這類不是單純付款問題,通常是 provider 資格、接案狀態或封鎖限制。

先查:

processWantToContactProvider log
provider user / profile / qualification
blocked user config

Queue / log 判斷提醒

若排查結果牽涉 downstream event,不要只查原 queue table。

event_queue 或 event_queue_log_1..event_queue_log_4 任一存在即可
task_event_queue 或 task_event_queue_log 任一存在即可

維護原則

  • 只收錄會反覆用來排查的 channel / error code。
  • 新增 error code 時要連到對應 endpoint 或 business flow。
  • 不在這份索引貼完整 request / response token 或 staging 個案 ID。
  • 如果錯誤只存在於某次 migration,放 專案 migration detail,不放這裡。