| name | hosted-studio-debug |
| description | Debug GenLayer Studio deployments via ArgoCD CLI |
Hosted Studio Debug Skill
Debug GenLayer Studio deployments via ArgoCD CLI.
Workload Manifests
Kubernetes manifests are in sibling repo ../devexp-apps-workload (assume by default, ask user if not found):
devexp-apps-workload/workload/
├── dev/ # studio-dev, rally-studio-dev
├── stg/ # studio-stg
├── prd/ # studio-prd, rally-studio-prd
Each contains Deployments, Services, Ingresses, ExternalSecrets managed by ArgoCD.
Prerequisites
- Logged into ArgoCD CLI
- Access to target cluster
Full Status Check
To get complete visibility into Studio status, check all components across all replicas:
argocd app get <app>-workload
argocd app resources <app>-workload --kind Pod
argocd app logs <app>-workload --name studio-consensus-worker --tail 500 2>&1 | grep -iE "(error|exception|timeout|failed)"
argocd app logs <app>-workload --name studio-jsonrpc --tail 500 2>&1 | grep -iE "(error|exception|timeout|failed)"
argocd app logs <app>-workload --name studio-webdriver --tail 200 2>&1 | grep -iE "(error|exception|crash)"
Quick Commands
argocd app get <app>-workload
argocd app resources <app>-workload
argocd app resources <app>-workload --kind Pod
argocd app logs <app>-workload --name studio-consensus-worker --tail 200
argocd app logs <app>-workload --name studio-jsonrpc --tail 200
argocd app logs <app>-workload --name studio-consensus-worker --tail 500 2>&1 | grep -i error
argocd app logs <app>-workload --name studio-jsonrpc --tail 500 2>&1 | grep -i error
Multi-Replica Log Access
Important: The argocd app logs --name <container> command automatically aggregates logs from ALL pod replicas. This ensures full visibility across the entire deployment.
argocd app logs <app>-workload --name studio-consensus-worker --tail 500
argocd app logs <app>-workload --name studio-jsonrpc --tail 500
argocd app logs <app>-workload --pod <pod-name> --tail 200
argocd app resources <app>-workload --kind Pod
Common Issues
Transaction Timeouts
Consensus worker timeouts usually mean GenVM Manager is unresponsive. Check all 4 workers in production:
argocd app logs <app>-workload --name studio-consensus-worker --tail 500 2>&1 | grep -E "(timeout|SocketTimeoutError|127.0.0.1:3999)"
argocd app logs <app>-workload --name studio-consensus-worker --tail 500 2>&1 | grep "stdout=''"
Root cause: GenVM Manager (genvm-modules manager --port 3999) becomes unresponsive.
Fix: Worker restart (auto or manual) restarts GenVM Manager.
Key files:
backend/node/genvm/origin/base_host.py:463 - where timeouts occur
backend/node/base.py - Manager.create() spawns GenVM
backend/consensus/worker_service.py - worker startup/health
Pod Restarts
argocd app logs <app>-workload --name studio-consensus-worker --tail 500 2>&1 | grep -E "(Started|Uvicorn running)"
kubectl get pods -n <namespace> -o wide
kubectl get events -n <namespace> --sort-by='.lastTimestamp'
External API Failures
Contracts calling external APIs (Twitter, etc.) through proxies:
argocd app logs <app>-workload --name studio-consensus-worker --tail 500 2>&1 | grep -E "(HTTP|fetch|proxy|api)"
Environment Apps
| Env | App | Namespace |
|---|
| dev | studio-dev-workload | studio-dev |
| stg | studio-stg-workload | studio-stg |
| prd | studio-prd-workload | studio-prd |
| rally-prd | rally-studio-prd-workload | rally-studio-prd |
Components
| Component | Purpose | Prd Replicas | Common Issues |
|---|
| studio-consensus-worker | Tx processing | 4 | Timeouts, GenVM crashes |
| studio-jsonrpc | RPC API | 2 | DB connections |
| studio-webdriver | Browser sandbox | 1 | Memory, crashes |
| database-migration | Schema updates | 1 (job) | Lock contention |
Note: When debugging, always check logs from ALL replicas to get complete visibility. The argocd app logs --name <container> command handles this automatically.