Troubleshooting
When a CDB EdgeCompute application fails, the response includes a CDB EdgeCompute-specific 5xx status code. The code identifies whether the failure happened during initialization, execution, timeout, or memory allocation.
Start by identifying the returned status code. Then enable debug logging to capture application output and investigate the root cause.
HTTP error codes
| Code | Meaning | Common causes |
|---|---|---|
| 530 | Application initialization failed | Missing or invalid environment variable, wrong compilation target, corrupt binary |
| 531 | Runtime error — unhandled exception | Rust panic, JavaScript TypeError, failed outbound request, unexpected null |
| 532 | Execution timed out | Handler exceeded the execution time limit; check for infinite loops, expensive processing, or slow outbound calls |
| 533 | Memory limit exceeded | Application allocated more memory than the plan allows |
Debug logging
Production applications do not write logs by default. Enable debug mode before reproducing the issue to capture console.log output (JavaScript) or println! output (Rust).
Enable debug mode:
curl -X PATCH "https://api.cdb-staging.cdn.orange.com/edgecompute/v1/apps/{app_id}" \
-H "Authorization: APIKey $GCORE_API_KEY" \
-H "Content-Type: application/json" \
-d '{"debug": true}'
Debug mode stays active for 30 minutes and then turns off automatically. Reproduce the failure, then retrieve the logs:
curl "https://api.cdb-staging.cdn.orange.com/edgecompute/v1/apps/{app_id}/logs" \
-H "Authorization: APIKey $GCORE_API_KEY"
Available query parameters: from, to, edge (specific PoP), client_ip, request_id, search.
Platform limits
Exceeding the limits below triggers a 532 (timeout) or 533 (memory) response. Check which plan your application is on if you see these codes repeatedly.
| Resource | Basic | Pro |
|---|---|---|
| Execution time | 50 ms | 200 ms |
| Memory | 128 MB | 256 MB |
| Outbound requests | 5 per invocation | 20 per invocation |
| Request / response body | 1 MB | 5 MB |
| Binary size | ~50 MB | ~50 MB |
Common application issues
Rust: log output not appearing
eprintln! writes to stderr, which CDB EdgeCompute does not capture. Use println! for any output that should appear in debug logs.
JavaScript: unavailable APIs
The following are not available inside CDB EdgeCompute JavaScript applications:
- Node.js built-ins:
node:crypto,node:fs,node:buffer,process,require WebSocket- Web Cache API — use the Cache module (
import { Cache } from 'edgecompute::cache') instead
Local testing
Before deploying, test your application locally using the CDB EdgeCompute CLI. See CDB EdgeCompute CLI for installation and full usage.
# Run a Wasm binary as a local HTTP server
edgecompute-run http -w ./app.wasm --port 8080
# Launch the visual debugger at http://localhost:3000
edgecompute-test
For JavaScript applications, npm run debug starts the same visual debugger.
Related resources
| Resource | Link |
|---|---|
| Rust SDK examples | github.com/G-Core/CDB EdgeCompute-sdk-rust/examples |
| JavaScript SDK examples | github.com/G-Core/CDB EdgeCompute-sdk-js/examples |
| AssemblyScript SDK examples | github.com/G-Core/proxy-wasm-sdk-as/examples |
| Rust SDK | github.com/G-Core/CDB EdgeCompute-sdk-rust |
| Rust API reference | docs.rs/edgecompute |
| JavaScript SDK | github.com/G-Core/CDB EdgeCompute-sdk-js |
| JavaScript reference | g-core.github.io/CDB EdgeCompute-sdk-js |
| AssemblyScript SDK (CDN apps) | github.com/G-Core/proxy-wasm-sdk-as |
| MCP server | [github.com/G-Core/CDB EdgeCompute-mcp-server](https://github.com/G-Core/CDB EdgeCompute-mcp-server) |
| VSCode extension | [github.com/G-Core/CDB EdgeCompute-vscode](https://github.com/G-Core/CDB EdgeCompute-vscode) |
| CDB EdgeCompute Test | [github.com/G-Core/CDB EdgeCompute-test](https://github.com/G-Core/CDB EdgeCompute-test) |