agentleFS
genlayerlabsgenlayerlabs/genlayer-studio/.claude/skills/hosted-studio-debug/SKILL.md

hosted-studio-debug

Skill180 starsChanged 8 months agoMITView on GitHub

Debug GenLayer Studio deployments via ArgoCD CLI

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Note: When debugging, always check logs from ALL replicas to get complete visibility.

    line 150

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

# 1. Overall app health
argocd app get <app>-workload

# 2. List all pods and their status
argocd app resources <app>-workload --kind Pod

# 3. Check consensus worker logs (all 4 replicas in prd)
argocd app logs <app>-workload --name studio-consensus-worker --tail 500 2>&1 | grep -iE "(error|exception|timeout|failed)"

# 4. Check JSON-RPC logs (all 2 replicas in prd)
argocd app logs <app>-workload --name studio-jsonrpc --tail 500 2>&1 | grep -iE "(error|exception|timeout|failed)"

# 5. Check webdriver logs
argocd app logs <app>-workload --name studio-webdriver --tail 200 2>&1 | grep -iE "(error|exception|crash)"

Quick Commands

# Check app health
argocd app get <app>-workload

# List all resources (pods, deployments, services, etc.)
argocd app resources <app>-workload

# List all pods with their status
argocd app resources <app>-workload --kind Pod

# Tail consensus worker logs (aggregates from ALL replicas)
argocd app logs <app>-workload --name studio-consensus-worker --tail 200

# Tail JSON-RPC logs (aggregates from ALL replicas)
argocd app logs <app>-workload --name studio-jsonrpc --tail 200

# Check for errors across all replicas
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.

# Get logs from all consensus worker replicas (production has 4)
argocd app logs <app>-workload --name studio-consensus-worker --tail 500

# Get logs from all JSON-RPC replicas (production has 2)
argocd app logs <app>-workload --name studio-jsonrpc --tail 500

# Get logs from a specific pod (if needed for isolation)
argocd app logs <app>-workload --pod <pod-name> --tail 200

# List pods first to get pod names
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:

# Check for GenVM timeouts across all consensus worker replicas
argocd app logs <app>-workload --name studio-consensus-worker --tail 500 2>&1 | grep -E "(timeout|SocketTimeoutError|127.0.0.1:3999)"

# Empty stdout = GenVM never started
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

# Check restart timestamps in logs
argocd app logs <app>-workload --name studio-consensus-worker --tail 500 2>&1 | grep -E "(Started|Uvicorn running)"

# Via kubectl
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:

# Check for HTTP errors in contract execution
argocd app logs <app>-workload --name studio-consensus-worker --tail 500 2>&1 | grep -E "(HTTP|fetch|proxy|api)"

Environment Apps

EnvAppNamespace
devstudio-dev-workloadstudio-dev
stgstudio-stg-workloadstudio-stg
prdstudio-prd-workloadstudio-prd
rally-prdrally-studio-prd-workloadrally-studio-prd

Components

ComponentPurposePrd ReplicasCommon Issues
studio-consensus-workerTx processing4Timeouts, GenVM crashes
studio-jsonrpcRPC API2DB connections
studio-webdriverBrowser sandbox1Memory, crashes
database-migrationSchema updates1 (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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.