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

1. 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.
2. 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.
3. 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.
4. 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.
5. EXECUTION RULE FOR ERRORS: On any API error, log [WARN] <category>: <message> 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.
6. 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.
7. 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.