-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Problem
The Go compiler repeatedly crashes when compiling the gqlgen-generated generated.go file (88,298 lines / 2.8MB). This has caused three Proxmox host freezes, taking down DNS/DHCP for the entire network. The crashes occur during:
gqlgen generate— SIGBUS/page fault during codegengo test -coverprofile— coverage-instrumented compilation exhausts memory- CodeQL Go analysis — compiles the full backend
Remediation steps attempted:
- Upgraded gqlgen v0.17.70 → v0.17.88
- Upgraded Go to 1.25 (newer compiler)
- Disabled runner-2 (single runner only)
- Cleaned Go build/test caches on runner
- Bumped VM RAM 8GB → 16GB
- Split generated.go into smaller files (held in reserve)
Steps 1-4 fixed gqlgen and CodeQL crashes, but go test -coverprofile (SonarQube backend analysis) still crashes the host. The runner is currently stopped and disabled to protect network stability.
Root cause
A single 88K-line generated file is an unreasonable demand on the Go compiler's memory. This is a fundamental architectural problem with gqlgen's code generation approach.
Solution
Replace the Go backend with .NET 10 / EF Core 10 using Hot Chocolate for GraphQL. Hot Chocolate is code-first with zero codegen — the 88K-line file problem cannot exist.
See docs/GRAPHQL-ALTERNATIVES.md for full alternatives analysis and docs/DOTNET-MIGRATION-PLAN.md for the detailed replacement plan.
Scope
- Phase 0: Scaffold .NET solution, mirror EF Core models from GORM, verify parity
- Phase 1: Private GraphQL (dashboard API) via Hot Chocolate
- Phase 2: Public GraphQL (data ingestion) via Hot Chocolate
- Phase 3: Kafka workers as BackgroundServices
- Phase 4: Integrations + Auth
- Phase 5: Cut over, remove Go backend
Acceptance criteria
- .NET solution compiles and runs
- EF Core models match PostgreSQL schema
- Hot Chocolate serves private GraphQL queries
- No codegen files, no compiler crashes
- CI runs without crashing the host