🐛 Bugfix: Why couldn't Studio find the GitLab repo after successful ge...

Date: 2026-03-11
Time: 15:05:10 UTC
Session: gspace1-203.7
Agent: backend
Confidence: 97%
Status: ✅ Documented

📋 Decision Context

Question:

Why couldn't Studio find the GitLab repo after successful generation?

Task: S203: Fix Studio unable to load git state

🎯 Decision Made

Chosen:

gitConfig was never persisted to the universe MongoDB document. initializeRepo() returned gitConfig in-memory but no code saved it. StudioGitController reads universe.gitConfig from MongoDB via GET /api/spaces/:spaceId/universes/:universeId — it was always null. Fixed by adding PUT to persist gitConfig immediately after pre-flight init.

Options Considered:

1. Persist gitConfig in pre-flight phase via PUT to universe
2. Have Studio call initializeRepo on-demand if gitConfig missing
3. Store gitConfig in a separate collection

💭 Reasoning

The Studio's git panels (branches, history, deploy) all call getGitConfig() which reads universe.gitConfig from MongoDB. The generation pipeline called initializeRepo() which creates the GitLab repo and returns a gitConfig object, but this object was only used in-memory during the generation session. After the process ended, the gitConfig was lost. The universe document in MongoDB still had gitConfig: undefined. This is a classic 'write-through' bug — the creation happened but the reference wasn't stored. Early warning: any time a service creates external resources (GitLab repos, R2 buckets, Cloudflare projects), the reference must be persisted to the owning document in the same transaction or immediately after.

📁 Files Involved

• APIs/backend-vitto-api/src/app/module-generation/phases/module-gen-phase.executor.ts
• APIs/backend-vitto-api/src/app/studio/studio-git.controller.ts

🔗 Related

• Decision ID: dev_1773241510010_elsfgpo
• Session: 203
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation