cloud-functions

Cloud Functions Development

Activation Contract

Use this first when

• The task is to create, update, deploy, inspect, or debug a CloudBase Event Function or HTTP Function.

Read before writing code if

• The request mentions runtime, HTTP function, scf_bootstrap, function logs, or function deployment.

Then also read

• Auth setup or provider-related backend work -> ../auth-tool/SKILL.md
• AI in functions -> ../ai-model-nodejs/SKILL.md

Do NOT use for

• CloudRun container services or Web authentication UI implementation.

Common mistakes / gotchas

• Picking the wrong function type and trying to compensate later.
• Mixing Event Function code shape (exports.main(event, context)) with HTTP Function code shape (req / res on port 9000).
• Treating HTTP Access as the implementation model for HTTP Functions. HTTP Access is a gateway configuration for Event Functions, not the HTTP Function runtime model.
• Forgetting that runtime cannot be changed after creation.
• Using cloud functions as the first solution for Web login.
• Forgetting that HTTP Functions do NOT auto-install dependencies — always include node_modules.
• Forgetting to add app.use(express.json()) or equivalent body parsing middleware for POST/PUT requests.
• Leaving HTTP handlers without sending a response (causes request timeout).
• Not returning proper HTTP status codes (400, 401, 405) for error cases.

Minimal checklist

• Read Cloud Functions Execution Checklist before deployment or runtime changes.

Overview

Use this skill when developing, deploying, and managing CloudBase cloud functions. CloudBase supports two types of cloud functions:

• Event Functions (普通云函数): Traditional serverless functions triggered by events (SDK calls, timers)
• HTTP Functions (HTTP 云函数): Web service functions triggered by HTTP requests, supporting multiple languages

Writing mode at a glance

• If the request is for a normal CloudBase function triggered by SDK calls, timers, or other events, write an Event Function with exports.main = async (event, context) => {}.
• If the request is for an HTTP endpoint, REST API, SSE, or WebSocket service, write an HTTP Function that listens on port 9000 and handles req / res.
• If the user mentions HTTP access for an existing Event Function, keep the Event Function code shape and add gateway access separately.

When to use this skill

Use this skill for cloud function operations when you need to:

• Create and deploy Event Functions (Node.js)
• Create and deploy HTTP Functions (Node.js/Python/Go/Java)
• Understand runtime limitations and selection
• Query function logs and monitor execution
• Invoke cloud functions from applications
• Configure HTTP access for cloud functions
• Implement SSE (Server-Sent Events) or WebSocket

Do NOT use for:

• CloudRun backend services (use cloudrun-development skill)
• Complex container-based services (use cloudrun-development skill)
• Database operations (use database skills)

How to use this skill (for a coding agent)

1. Choose the right function type

   • Event Function: For SDK calls, scheduled tasks, event-driven scenarios
   • HTTP Function: For Web APIs, REST services, SSE/WebSocket, multi-language support
   • If the prompt says "HTTP 云函数", use the HTTP Function model first; if it says "触发器云函数" or omits HTTP, default to the Event Function model.

2. Understand runtime limitations

   • Runtime CANNOT be changed after function creation
   • Must select correct runtime during initial creation
   • If runtime needs to change, must delete and recreate function

3. Write code AND deploy — do not stop after writing files

   • CRITICAL: After writing function code, you MUST also deploy it using manageFunctions. Creating files locally without deploying is incomplete.
   • Use manageFunctions(action="createFunction") to create AND deploy in one step
   • Provide functionRootPath as the parent directory of the function folder (e.g., /project/cloudfunctions/ not /project/cloudfunctions/myFunction/)
   • Preferred MCP Tools: Use queryFunctions for reads, manageFunctions(action="createFunction") for creation, and manageFunctions(action="updateFunctionCode") for code updates
   • Legacy compatibility: If older prompts mention createFunction / updateFunctionCode, map them to the manageFunctions actions above
   • CLI: Use tcb fn deploy (Event) or tcb fn deploy --httpFn (HTTP) only as a fallback when MCP tools are unavailable
   • In agent / non-interactive runs, never default to CLI login flows for deployment; keep the flow on manageFunctions
   • For HTTP functions, create or update them through manageFunctions with func.type="HTTP" as the primary path
   • HTTP Functions require scf_bootstrap file in the function directory
   • Provide correct functionRootPath (parent directory of function folder)

4. Query logs properly

   • Use queryFunctions(action="listFunctionLogs") for log list (basic info)
   • Use queryFunctions(action="getFunctionLogDetail") with RequestId for detailed logs
   • Legacy compatibility: Treat getFunctionLogs / getFunctionLogDetail as the two queryFunctions actions above
   • Note time range limitations (max 1 day interval)

5. Handle legacy tool names safely

   • Prefer the converged entrances: queryFunctions, manageFunctions, queryGateway, manageGateway
   • If old names appear in historical docs or prompts, convert them before acting:
     • getFunctionList -> queryFunctions
     • createFunction -> manageFunctions(action="createFunction")
     • updateFunctionCode -> manageFunctions(action="updateFunctionCode")
     • updateFunctionConfig -> manageFunctions(action="updateFunctionConfig")
     • getFunctionLogs -> queryFunctions(action="listFunctionLogs")
     • getFunctionLogDetail -> queryFunctions(action="getFunctionLogDetail")
     • manageFunctionTriggers -> manageFunctions(action="createFunctionTrigger"|"deleteFunctionTrigger")
     • readFunctionLayers -> queryFunctions(action="listLayers"|"listLayerVersions"|"getLayerVersionDetail"|"listFunctionLayers")
     • writeFunctionLayers -> manageFunctions(action="createLayerVersion"|"deleteLayerVersion"|"attachLayer"|"detachLayer"|"updateFunctionLayers")
     • createFunctionHTTPAccess -> manageGateway(action="createAccess")

---

Function Types Comparison

Feature	Event Function (普通云函数)	HTTP Function (HTTP 云函数)
Trigger	Event-driven (SDK, timer)	HTTP request
Entry Point	exports.main = async (event, context) => {}	Web Server (Express/Flask/Gin etc.)
Port	No port required	Must listen on port 9000
Bootstrap	Not required	Requires scf_bootstrap
Connection	Short connection	Supports long connection
Languages	Node.js only	Node.js, Python, Go, Java
Protocols	N/A	HTTP, SSE, WebSocket
Use Cases	Event processing, scheduled tasks	Web APIs, REST services, real-time streaming

---

Core Knowledge - Event Functions

Runtime Environment

⚠️ CRITICAL: Runtime cannot be modified after function creation

Once a cloud function is created with a specific runtime, the runtime cannot be changed. If you need a different runtime:

1. Delete the existing function
2. Create a new function with the desired runtime

Supported Node.js Runtimes:

• Nodejs18.15 (Default, Recommended)
• Nodejs16.13
• Nodejs14.18
• Nodejs12.16
• Nodejs10.15
• Nodejs8.9

Runtime Selection Guidelines:

• Use Nodejs18.15 for new projects (default, most modern)
• Choose older versions only if dependencies require specific Node.js versions
• Consider security updates and support lifecycle
• Test thoroughly with selected runtime before deployment

Event Function Structure

Event functions require:

1. Function Directory: Contains function code

   • Must have index.js (or specified entry file)
   • Must export handler: exports.main = async (event, context) => {}
   • Include package.json with dependencies

2. Function Root Path: Parent directory containing function directories

   • Example: If function is at /project/cloudfunctions/myFunction/
   • functionRootPath should be /project/cloudfunctions/
   • Important: Do NOT include function name in root path

3. Entry Point: Default is index.js with exports.main

   • Can be customized via handler parameter

Event Function Deployment

Creating New Functions:

Use manageFunctions(action="createFunction") (see MCP tool documentation for full parameter list):

• Important: Always specify func.runtime explicitly (defaults to Nodejs18.15)
• Provide functionRootPath as parent directory of function folders (absolute path)
• Use force=true to overwrite existing function
• Legacy compatibility: If an older prompt says createFunction, keep the same payload but send it through manageFunctions

Updating Function Code:

Use manageFunctions(action="updateFunctionCode"):

• ⚠️ Note: Only updates code, cannot change runtime
• If runtime needs to change, delete and recreate function
• Legacy compatibility: If an older prompt says updateFunctionCode, map it to this manageFunctions action

Deployment Best Practices:

1. Always specify runtime explicitly when creating functions
2. Use absolute paths for functionRootPath
3. Don't upload node_modules - dependencies installed automatically
4. Test locally before deployment when possible
5. Use environment variables for configuration, not hardcoded values

---

Core Knowledge - HTTP Functions

HTTP Function Overview

HTTP Functions are optimized for Web service scenarios, supporting standard HTTP request/response patterns.

**HTTP Function codi

---

Content truncated.