Alibaba Cloud OSS Event Notification & Upload Callback Diagnosis

安装指南

1. ClawHub CLI 从源直接安装技能的最快方式。
   npx clawhub@latest install alibabacloud-oss-event-notification-diagnosis
2. 手动安装 将技能文件夹复制到以下位置之一
   全局模式
   ~/.openclaw/skills/
   工作区
   /skills/
   优先级：工作区 > 本地 > 内置
3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
   请帮我使用 Clawhub 安装 alibabacloud-oss-event-notification-diagnosis。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。
   更倾向于下载？
   获取包含原生技能文件的ZIP压缩包。
   下载技能 (.zip)

什么是

此 Openclaw Skills 诊断工具可检查 Alibaba Cloud Object Storage Service (OSS) 事件通知未触发或上传回调失败的原因。其入口脚本会验证 bucket 和 region，读取通知规则和 bucket 级别的 callback 策略，将配置的规则与预期事件进行比较，并将提供的 callback 错误归因于固定 5 秒响应限制、HTTP 502、非 JSON 响应、HTTPS/SNI 问题或格式错误的 callback 参数等原因。
该技能严格保持只读：它不会创建、编辑、删除、测试或修复 OSS 资源，也绝不会探测 callback URL。诊断结果基于脚本输出，报告错误和局限性，而非凭空猜测。Openclaw Skills 用户可以获得可操作的手动指导，同时将诊断活动保持在明确、可审计的边界内。
Alibaba Cloud OSS Event Notification & Upload Callback Diagnosis 应用场景
OSS 事件通知未触发或 MNS/SMQ 队列未收到消息。
上传返回 203 CallbackFailed ，伴随 HTTP 502 或其他 callback 错误。
callback 在固定的 5 秒响应限制附近超时。
您需要检查 bucket 是否配置了通知规则或 callback 策略。
您希望将预期的事件类型（例如
ObjectCreated:PutObject
）与 bucket 配置的规则进行比较。
您需要基于证据的排查，同时避免修改配置或进行测试上传。
问题实际上与计费、访问日志、endpoint 选择或错误码解释有关；请将其路由至相应的兄弟技能。
Alibaba Cloud OSS Event Notification & Upload Callback Diagnosis 工作原理
收集所需的 bucket 名称和任何有用的上下文：预期的 region、预期的事件类型、观察到的 callback 错误、callback URL 或客户的原始问题。
运行身份辅助程序，该程序通过 aliyun CLI 默认凭据链导出 UID 以实现可追溯性。不会请求或打印凭据。
运行 scripts/oss_event_notification_diagnosis.py，这是强制性的诊断入口点。它会确认 bucket 并通过 GetBucketInfo 导出其真实的 region。
使用 GetBucketNotification 读取 bucket 的通知规则，并使用 GetBucketCallbackPolicy 读取 callback 策略。缺失通知配置或 callback 策略会作为发现结果予以报告，不会错误陈述为 API 失败。
将预期事件与配置的规则进行匹配，并使用脚本的发现结果归因所提供的 callback 错误文本。该技能不会向 callback URL 发起网络请求，也不会重现上传。
解读结构化报告和参考模块，然后提供状态、基于证据的结论、记录的局限性、下一步操作以及任何自动填充的参数。对于配置或使用问题，请使用 --question 调用脚本，并仅引用其验证输出返回的官方文档 URL。
Alibaba Cloud OSS Event Notification & Upload Callback Diagnosis 配置指南
确保已安装 Alibaba Cloud CLI 且版本为 3.3.3 或更高。如果需要，请升级现有安装：
aliyun version # must be 3.3.3 or newer
aliyun upgrade --yes
如果尚未身份验证，请配置 CLI 的默认凭据链。该技能不直接接收或请求 access key：
aliyun configure
OSS SDK 调用使用默认凭据链，包括 ALIBABA_CLOUD_ACCESS_KEY_ID、ALIBABA_CLOUD_ACCESS_KEY_SECRET 以及可选的 ALIBABA_CLOUD_SECURITY_TOKEN。身份检查使用 aliyun CLI 默认凭据链。切勿显式打印或传递凭据。
在已安装技能的目录下，可选检查调用者身份，然后使用 bucket 名称运行诊断：
cd "$SKILL_DIR"
python3 scripts/sts_token.py
python3 scripts/oss_event_notification_diagnosis.py
--bucket
[--region ] \
[--expected-event ] \
[--callback-error ""] \
[--callback-url ]
对于需要官方文档验证的配置或使用问题，请使用 --question "" 附带客户的原始表述。仅引用在 doc_verification.docs 中返回的 URL；如果其备注以 DEGRADED 开头，请说明在线官方文档验证不可用。
这些脚本仅执行只读检查。切勿提供修改 OSS 资源、上传测试对象或发送 callback 请求的命令。如果用户要求修改配置，请提供手动控制台指导并解释此技能无法应用修改。
Alibaba Cloud OSS Event Notification & Upload Callback Diagnosis 数据架构与分类体系
诊断会输出结构化的 JSON 报告以及 STATUS 和 NEXT_ACTION 等契约行。仅解读实际报告中存在的字段；失败或不可用的查询必须保持为明确的局限性。
Report data Role
status 总体结果，包括可用的 OK 或 DEGRADED 结果；缺少必需的输入或不可用的证据可能会产生 FAIL。
event_notification 来自 bucket 通知配置的发现结果，包括规则是否存在以及它们是否覆盖预期事件。
upload_callback 与 callback 相关的发现结果以及针对提供的错误文本生成的任何错误归因。
verdict / findings 基于只读查询结果的诊断结论。
auto_filled 自动提供或导出的参数，例如 region 或 UID；请在响应中说明这些参数。
errors[] 结构化的错误详情，包括类别、代码、消息以及返回的提示。降级的步骤也会在 stderr 上记录为 [WARN]。
recommendations 为用户提供的基于证据的建议；配置更改仅为手动指导。
next_action 当输入或证据缺失或降级时脚本请求的后续操作。
doc_verification 对于 --question 路径，代表验证状态以及查询返回的官方文档标题和 URL。
该技能的支撑文件包括 scripts/oss_event_notification_diagnosis.py（诊断入口点）、scripts/sts_token.py（身份辅助程序）、scripts/_oss_client.py（共享客户端行为）和 scripts/_doc_lookup.py（官方文档查询）。参考模块涵盖事件规则、callback 排查和最小只读 RAM 权限。references/manifest.json 是请求可观测性中所用技能版本的唯一来源。
Alibaba Cloud OSS Event Notification & Upload Callback Diagnosis 高级特性
只读强制执行：
仅使用身份和 OSS 读取操作；绝不变更规则或策略，不上传测试文件，不探测 callback，也不重现症状。
强制性诊断脚本：
通过提供的脚本路由云查询，而不是通过临时的 SDK、ossutil 或 curl 命令。
感知证据的降级：
记录 API 错误、发出警告、在可能的情况下继续其余检查，并将可用的降级结果与失败区分开。
Callback 归因：
对照已文档化的原因解读提供的错误文本，包括 HTTP 502、超时、响应格式/状态要求、HTTPS/SNI 行为以及格式错误的 callback 参数。
Region 和身份处理：
GetBucketInfo
导出 bucket 的实际 region，并在可导出时获取用于追溯的 UID，无需要求用户提供。
请求可观测性：
在 API 请求标识中添加每次运行的 session ID 和从 manifest 导出的技能版本以进行关联。
官方文档验证： --question 路径检查内置知识和官方 OSS 文档；最终响应必须仅使用返回的文档 URL。
感知范围的路由：
明确将访问日志追踪、传输错误码参考、endpoint 问题和计费延迟到其指定的兄弟技能。

name: alibabacloud-oss-event-notification-diagnosis description: | Read-only OSS event notification and upload callback diagnostics. Use
when event notifications do not trigger (rule configuration check,
dependent service activation, event type matching) or upload callbacks
fail (CallbackFailed, callback 502, 5-second response limit, certificate
and network issues), plus configuration-correctness advice. Triggers:
"event notification not triggering", "upload callback failed",
"CallbackFailed error", "callback 502", "callback timeout 5 seconds",
"OSS event to MNS", "x-oss-event-status". Only checks and advises;
never creates or modifies notification rules. Do NOT use for
access-log tracing (use
alibabacloud-oss-access-log-trace-diagnosis), error codes (use
alibabacloud-oss-transfer-error-code-diagnosis), endpoint issues (use
alibabacloud-oss-endpoint-internal-diagnosis), or billing (use
alibabacloud-oss-billing-diagnosis).

OSS Event Notification & Upload Callback Diagnosis

Diagnose Alibaba Cloud OSS event-notification and upload-callback problems: "I configured an event notification rule but no message ever arrives", "my uploads return 203 CallbackFailed with Error status 502", "the callback server never receives the request", "does my bucket have any notification rule configured".

Core approach: verify the caller identity, confirm the bucket exists and locate its region with the read-only GetBucketInfo query, read the bucket's event-notification rules (GetBucketNotification) and its bucket-level callback policy (GetBucketCallbackPolicy), match the user's expected event type against the configured rules, and attribute CallbackFailed-style errors to a concrete cause (5-second response limit, non-JSON body, 502/unreachable callback server, HTTPS/SNI certificate, malformed callback parameter). Conclude with evidence-based findings only; this skill never creates or modifies any notification rule or callback policy.

Absolute Rules

ABSOLUTE PROHIBITION (read-only enforcement): Under NO circumstances may you generate, write, or execute any command/script calling a mutating OSS API - e.g. PutBucketNotification, PutBucketCallbackPolicy, DeleteBucketCallbackPolicy, PutObject*, DeleteBucket*, or any configuration change. This includes commands "for the user to run manually". If the user asks to create/modify/delete an event-notification rule or callback policy, only output manual console guidance and declare this skill is read-only.
MANDATORY entry-point enforcement: All diagnostics MUST be performed by running the scripts under scripts/ (oss_event_notification_diagnosis.py as the entry, sts_token.py for identity). The Agent is forbidden from assembling its own ossutil / SDK / curl commands against the OSS control plane or bypassing the scripts - the scripts embed timeout, error degradation, and observability guarantees that ad-hoc commands lack. Read the script output, interpret it, and compose the report; do not re-implement the queries.
ABSOLUTE PROHIBITION (credential handling): Never read, print, or pass AK/SK/STS tokens explicitly. The OSS SDK resolves credentials exclusively from the environment variables of the default credential chain; the identity check uses the aliyun CLI default credential chain. Never accept AK/SK from the user or from another script.
NO FABRICATION: Every conclusion must be grounded in data actually returned by GetBucketInfo / GetBucketNotification / GetBucketCallbackPolicy / GetCallerIdentity. If a query fails or returns empty, record it and state the limitation - never invent configured rules, event types, or callback statuses. When "no rule configured" (404 NoSuchNotificationConfiguration) is returned, report it as the semantic finding "event notification is not configured" - NOT as an error.
EXECUTION RULE FOR ERRORS: On any API error, log [WARN] : to stderr, continue with the remaining steps, and still produce the final report with STATUS: DEGRADED and a NEXT_ACTION line - never silently skip or abort without a report.
SCOPE BOUNDARY: This skill only answers event-notification triggering and upload-callback failure attribution questions. It CANNOT query the activation state of dependent services (SMQ/MNS, EventBridge) directly - no such read API is available to this skill; instead it states this limitation and gives the console check path. It does not handle billing, error-code glossaries, endpoint selection, or access-log tracing - defer to the sibling skills named in the frontmatter.
ABSOLUTE PROHIBITION (no write to verify, no reproduction): Never try to make the reported symptom happen again, and never "verify", "test", "validate" or "repair" a configuration by issuing a write: no object upload, copy, append, multipart-complete or delete (PutObject / PostObject / AppendObject / CompleteMultipartUpload / DeleteObject), no request carrying an x-oss-callback header, no test bucket, test object, test rule or test policy. Attribution is built only from the read-only queries run by scripts/ plus the error text the customer supplies. Empty / not-found is a valid, complete result: NoSuchBucket, "event notification not configured", "no callback policy configured" or an empty rule list must be reported as the conclusion and then stop - never react to such a result with a mutating call, and never fall back to hand-written ossutil / SDK / curl commands to force more evidence.

Official Doc Verification

MANDATORY: For configuration or usage questions, the entry script MUST be invoked with --question "". The script first matches embedded knowledge, then verifies against official OSS docs (doc_verification, llms-index). The final answer MUST cite the URLs from doc_verification.docs. If doc_verification.note starts with DEGRADED, state explicitly: "Unable to verify against online official docs (offline)." Never fabricate doc URLs; only URLs returned by the script may be cited.

Trigger Conditions

Use this skill when the customer's own wording matches one of these phrases (the same list the description advertises):

"event notification not triggering"
"upload callback failed"
"CallbackFailed error"
"callback 502"
"callback timeout 5 seconds"
"OSS event to MNS"
"x-oss-event-status"

Do NOT use it for the following -- those belong to a sibling skill:

Customer topic Route to

access-log tracing alibabacloud-oss-access-log-trace-diagnosis
error codes alibabacloud-oss-transfer-error-code-diagnosis
endpoint issues alibabacloud-oss-endpoint-internal-diagnosis
billing alibabacloud-oss-billing-diagnosis

A customer rarely states the technical cause; match on the symptom sentence, the error code or the EC number, not on product vocabulary. When the customer gives no way to locate the resource, still run the entry script: it exits STATUS: FAIL with a NEXT_ACTION naming the missing input and lists the buckets visible to the current credential, which is what should be put back to the customer.

Execution Principle

All diagnostics MUST be performed by running the scripts under scripts/. Read the structured JSON report, interpret status / verdict fields / recommendations, and compose the user-facing answer; do not re-implement the queries or call OSS APIs directly.

Observability

All API calls issued by the scripts include:

User-Agent template: AlibabaCloud-Agent-Skills/{skill-name}/{session-id} skill-version/{skill-version}, where {skill-name} is alibabacloud-oss-event-notification-diagnosis
skill-version: read at runtime from references/manifest.json (version), the single place where this skill's version is declared. It is never hardcoded, guessed or reused: the entry script resolves and validates it before the first cloud call and stops with STATUS: FAIL (exit 1) when the manifest is missing or its version is invalid.
session-id: 32-character hex string (uuid.uuid4().hex) generated once per script run and attached to every OSS SDK request (User-Agent header) and every --user-agent argument of the aliyun CLI identity call of that run, so all calls of one diagnosis can be correlated.

The shared client layer (scripts/_oss_client.py) implements this automatically: the session-id is generated lazily on the first call of each run and cached for the rest of the run, and the skill-version is resolved lazily from references/manifest.json on the first User-Agent build.

Exit codes (contract) 0 -- the run produced a conclusion: STATUS: OK, or STATUS: DEGRADED when part of the evidence was unavailable (the missing steps are recorded in errors[] and as [WARN] lines on stderr; the conclusion is still usable). 1 -- no usable conclusion: STATUS: FAIL, because required input is missing or every evidence call failed. NEXT_ACTION states what to ask the user for or what to fix; do not treat this as a success. 2 -- argparse usage error only (unknown option). A diagnosed condition never exits with 2.

Credentials

Credentials are resolved exclusively by the default credential chain:

OSS control-plane calls (Python oss2 SDK): the environment variables ALIBABA_CLOUD_ACCESS_KEY_ID, ALIBABA_CLOUD_ACCESS_KEY_SECRET, and optionally ALIBABA_CLOUD_SECURITY_TOKEN (STS sessions).
Identity check (aliyun sts get-caller-identity): the aliyun CLI default credential chain (environment or ~/.aliyun/config.json).

Do not read, print, or pass AK/SK/STS tokens explicitly. If the identity check fails, guide the user to run aliyun configure - never ask for AK/SK.

aliyun CLI version requirement

The scripts shell out to the aliyun CLI (at minimum the aliyun sts get-caller-identity identity pre-check), which MUST be version 3.3.3 or newer: older builds resolve the default credential chain differently and can drop the STS session token. Verify the installed version and upgrade it before the first run:

aliyun version # must print 3.3.3 or newer (measured with 3.4.5)
aliyun upgrade --yes # upgrade the installed CLI in place to the latest version

If the CLI is not installed at all, install the Alibaba Cloud CLI package for the host OS from the official release channel and then run aliyun configure (the profile stays in ~/.aliyun/config.json; this skill never asks for AK/SK). When the CLI is missing, too old to upgrade, or unauthenticated, the identity pre-check degrades instead of aborting: scripts/_oss_client.py logs [WARN] identity pre-check failed: ... on stderr, records the empty UID, and the diagnosis still runs to a conclusion, because the identity label is traceability only and never evidence.

cd $SKILL_DIR

# Verify caller identity (informational only; credentials always come from the default chain)
python3 scripts/sts_token.py

User Confirmation

Because every action of this skill is strictly read-only, no user confirmation is required before running the diagnostic scripts. Confirmation discipline applies at the scope boundary instead: when a request asks to create/modify/delete notification rules or callback policies, do not proceed with any mutation - output manual console guidance only and declare this skill is read-only (Absolute Rule 1).

Orchestration

One read-only script gathers evidence; the reference modules interpret it. Consult a module by responsibility, in this order:

Collect the inputs the report needs. Never guess a bucket or region: let the script's STATUS: FAIL output tell you what to ask, and offer only resources the credential can actually see.
Run scripts/oss_event_notification_diagnosis.py and read status, verdict/findings, auto_filled and errors[].
Interpret through the modules below; the diagnosis tree routes the symptom, the field-semantics module explains the failing check, and the RAM module names the permission to grant when category is permission.
Answer per the Final Answer Contract: verdict first, then the fix steps, then a declaration of every auto-filled parameter.
Module Responsibility (from Module Index)
M1: Event notification rules Rule limits, supported event types, dependent services, propagation delay, not-triggering checklist
M2: Callback troubleshooting CallbackFailed attribution tree, 5-second limit, JSON/200 requirements, HTTPS/SNI, malformed callback parameter
M3: RAM policies Minimal read-only RAM policy required by this skill

Documented run order: Step 1: Confirm Identity and Collect Inputs; Step 2: Run the Diagnosis; Step 3: Interpret the Findings and Advise; Step 4: Conclusion and Suggestions.

Input Parameters

Bucket name (--bucket): required; the OSS bucket to diagnose.
Expected region (--region): optional; used only to build the first query endpoint. The bucket's real region is always re-derived from GetBucketInfo before the notification query.
Expected event type (--expected-event): optional; the event the user expects to be notified (e.g. ObjectCreated:PutObject). Matched against the configured rules (exact match or group wildcard Group:*).
Observed callback error (--callback-error): optional; the exact error text of the failing upload (e.g. CallbackFailed, Message: Error status : 502.) used for root-cause attribution.
Callback URL (--callback-url): optional; the user's callbackUrl for a static form check (scheme/host/SNI notes). No network probe is issued from this skill.
UID: can always be omitted - it is derived via aliyun sts get-caller-identity and used only as a traceability label. Auto-fill first, ask second: never ask the user for UID when it can be derived.

Auto-fill declaration requirement: Whenever any parameter is auto-filled (query region defaulted, UID derived), the Agent MUST explicitly declare this in the response or report metadata.

Module Index

Reference modules, strictly 1:1 with the references/ directory:

Module File Responsibility

M1: Event notification rules references/event-notification-rules.md Rule limits, supported event types, dependent services, propagation delay, not-triggering checklist
M2: Callback troubleshooting references/callback-troubleshooting.md CallbackFailed attribution tree, 5-second limit, JSON/200 requirements, HTTPS/SNI, malformed callback parameter
M3: RAM policies references/ram-policies.md Minimal read-only RAM policy required by this skill

Diagnostic Flow

Step 1: Confirm Identity and Collect Inputs

Run python3 scripts/sts_token.py to verify credentials and derive the UID (traceability label only). Collect the bucket name and, when available, the expected event type or the exact callback error text. Map symptoms first with references/event-notification-rules.md or references/callback-troubleshooting.md.

Step 2: Run the Diagnosis
cd $SKILL_DIR && python3 scripts/oss_event_notification_diagnosis.py
--bucket [--region ] [--expected-event ]
[--callback-error ""] [--callback-url ]

The script:

Derives the caller UID via aliyun sts get-caller-identity (degraded with [WARN] on failure).
Calls OSS GetBucketInfo to confirm the bucket exists and derive its real region.
Calls OSS GetBucketNotification (signature V4, bucket's real region): a configured rule set is parsed; 404 NoSuchNotificationConfiguration becomes the semantic finding "event notification not configured".
Calls OSS GetBucketCallbackPolicy to check the bucket-level callback policy (404 BucketCallbackPolicyNotExist means "no policy configured").
Attributes any --callback-error text to a root cause and emits a structured JSON report plus the contract lines STATUS: OK | DEGRADED and NEXT_ACTION: .
Step 3: Interpret the Findings and Advise

Read event_notification and upload_callback from the report:

not configured - no rule exists on the bucket: notifications can never fire; give the manual console creation path (Data Processing > Event Notifications) and the SMQ/MNS activation prerequisite.
configured but event not covered - rules exist but none covers the expected event type or object prefix/suffix: advise extending/adding a rule (manual console task).
CallbackFailed attribution - relay the kind / attribution / advice: 5-second response limit, non-JSON body, 502 (server down / TLS-SNI / network), non-200 status, or malformed callback parameter.
dependent services - state honestly that SMQ/MNS or EventBridge activation/delivery cannot be queried by this skill; give the console check paths (SMQ/MNS console; EventBridge event tracing) and the x-oss-event-status response-header self-check.
DEGRADED report - relay the recorded errors and the NEXT_ACTION guidance honestly; never invent configured rules.
Step 4: Conclusion and Suggestions

Summarize the root cause with the actual fields from the report. Base the conclusion on the script's status / event_notification / upload_callback / recommendations / next_action fields rather than re-deriving them. Suggestions must be evidence-based and stated as manual guidance only (this skill never applies any change).

Important Notes

No-rule semantics: 404 NoSuchNotificationConfiguration is a finding ("event notification is not configured"), not an error - report it with STATUS: OK.
Propagation delay: a newly created rule takes about 10 minutes to take effect; a "not triggering" report right after rule creation must account for this window.
Dependent services: the legacy notification path requires SMQ (formerly MNS) activated; EventBridge delivery must be verified in the EventBridge console. This skill cannot query their state directly - never fabricate an activation status.
Versioned buckets: deleting without a versionId only adds a delete marker and does NOT fire ObjectRemoved events.
Callback timeout: the 5-second callback response limit is fixed and not configurable; the callback server must return HTTP 200 with a JSON body; upload succeeds + callback fails = HTTP 203 CallbackFailed (the object IS stored).
HTTPS/SNI: OSS does not send SNI by default; HTTPS callback servers relying on SNI need callbackSNI=true, otherwise the handshake fails and surfaces as a 502 CallbackFailed.
Read-only operations: only GetBucketInfo, GetBucketNotification, GetBucketCallbackPolicy, and sts:GetCallerIdentity; never modifies anything.

Examples

Example 1 - event notification not triggering

User: "I set up an event notification on bucket test-agentceping but my MNS queue receives nothing when files are uploaded. Account UID 1552974654746705."

python3 scripts/oss_event_notification_diagnosis.py --bucket test-agentceping --expected-event ObjectCreated:PutObject

Report the event_notification finding (configured or not, event coverage), the dependent-service console check path, the 10-minute propagation window, and declare any auto-filled parameters. If the report is STATUS: DEGRADED (e.g. missing RAM permission), relay the recorded errors and NEXT_ACTION honestly.

Example 2 - upload callback failed with 502

User: "Our PutObject with callback returns 203 CallbackFailed, Message: Error status : 502. The callback URL is https://cb.example.com/notify."

python3 scripts/oss_event_notification_diagnosis.py --bucket \

--callback-error "CallbackFailed, Message: Error status : 502."
--callback-url https://cb.example.com/notify

Relay the attribution (server not listening / TLS-SNI handshake failure / network path) and the advice (callbackSNI=true, curl verification for the customer to run on their own host - this skill never probes the callback URL itself, HTTP while debugging). The 5-second limit and JSON-body requirements come from the report's mechanism notes.

Example 3 - callback timeout

User: "Uploads fail intermittently with CallbackFailed saying reply timeout cost:5000ms."

python3 scripts/oss_event_notification_diagnosis.py --bucket \

--callback-error "CallbackFailed Error status : -1 reply timeout, cost:5000ms, timeout:5000ms"

Explain the fixed 5-second response limit and the async-processing advice from the report; never claim the limit is configurable.

Example N - Upload callback fails with CallbackFailed and HTTP 502

User: "My callback URL works from curl but OSS keeps reporting CallbackFailed with a 502, and the certificate is valid."

python3 scripts/oss_event_notification_diagnosis.py --bucket "my-bucket" --callback-error "502" --callback-url "https://api.example.com/callback"

Report the 5-second response budget and the SNI behaviour: several HTTPS sites behind one IP need callbackSNI set explicitly, otherwise the origin rejects the handshake; also verify the URL is publicly resolvable, not an intranet address.

Available Scripts

Script Purpose

scripts/sts_token.py Verify caller identity via aliyun sts get-caller-identity; derive the UID traceability label (--json optional)
scripts/oss_event_notification_diagnosis.py Diagnosis entry: GetBucketInfo + GetBucketNotification + GetBucketCallbackPolicy + CallbackFailed attribution

CLI options for oss_event_notification_diagnosis.py: --bucket (required), --region , --expected-event , --callback-error "", --callback-url (all optional).

Error Handling

Error Cause Resolution

No credentials found Environment credential chain not configured Run aliyun configure / configure environment variables; never ask the user for AK/SK
AccessDenied / 403 Missing read permission, bucket owned by another account, or wrong-region endpoint Record [WARN], point to references/ram-policies.md; report STATUS: DEGRADED
NoSuchBucket / 404 Bucket name does not exist (global namespace) Verify spelling and owning account; report STATUS: DEGRADED with NEXT_ACTION
NoSuchNotificationConfiguration / 404 Bucket has no event-notification rule NOT an error: report the semantic finding "event notification not configured" with STATUS: OK
BucketCallbackPolicyNotExist / 404 Bucket has no bucket-level callback policy NOT an error: report "no callback policy configured"; request-level callback parameters may still be in use
Network timeout / connection reset Transient network failure Report STATUS: DEGRADED honestly; retry later, never conclude "no problem" from a failed call
InternalError / 5xx / SlowDown Transient service-side failure or request throttling Retried automatically inside scripts/_oss_client.py (2 extra attempts, 1s then 3s, each traced as [WARN] on stderr); if the call still fails the report carries STATUS: DEGRADED. Do not re-run the script in a loop and never conclude "no problem" from a failed call

| Doc lookup module | scripts/_doc_lookup.py | Runtime official-doc verification against the OSS help center (llms-index); used by the --question path | All errors follow the structured category/code/message/hint shape recorded in the report's errors array; every degraded step logs [WARN] on stderr, and the report is always emitted with whatever data succeeded.

Final Answer Contract

The final answer to the user MUST:

Relay the script's STATUS: (OK / DEGRADED) and NEXT_ACTION: line verbatim in meaning.
State the root cause with the actual evidence fields (rule existence, event coverage, callback attribution) - no fabricated values.
Declare every auto-filled parameter (region default, UID derivation).
On DEGRADED, list the recorded errors and limitations explicitly instead of inventing conclusions; never fabricate the activation state of SMQ/MNS or EventBridge.
Give rule-creation / policy-change suggestions as manual console guidance only (this skill never applies changes).
When the report carries doc_verification, cite the doc titles and URLs from doc_verification.docs in the final answer; when doc_verification.note starts with DEGRADED, state explicitly: "Unable to verify against online official docs (offline)."
阿里云 OSS CDN 源站配置诊断
阿里云 OSS 预签名 URL 诊断与 V4 升级