Changed Development from false to true to test if this is preventing
debug logs from being output. Development mode may affect how the
logger handles different log levels.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Added Log.Debug() and Log.Info() calls immediately after Build()
to test if the logger can output debug logs right after creation.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Added debug output to track:
1. AtomicLevel value when created
2. AtomicLevel value after Build()
3. Log.Level() value after Build()
This will help identify if Build() or something else is changing the level.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Added println statements to trace:
1. Level value after UnmarshalText
2. Logger level after Build()
This will help diagnose why debug level is not being applied.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Problem: Logger was always using info level despite MPC_LOGGER_LEVEL=debug
Root cause: The init() function in logger.go was calling InitProduction()
which created a zap.NewProduction() logger with hardcoded info level.
This happened before main() called logger.Init(cfg), so the config was
being ignored.
Solution:
1. Removed init() function to prevent early logger initialization
2. Added zap.ReplaceGlobals() in Init() to ensure config takes effect
3. Removed unused "os" import
References:
- https://pkg.go.dev/go.uber.org/zap
- https://stackoverflow.com/questions/57745017/🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Remove Address field from PartyEndpoint (parties connect to router themselves)
- Update K8s Discovery to only manage PartyID and Role labels
- Add Party registration and SessionEvent protobuf definitions
- Implement PartyRegistry and SessionEventBroadcaster domain logic
- Add RegisterParty and SubscribeSessionEvents gRPC handlers
- Prepare infrastructure for party-driven MPC coordination
This is the first phase of migrating from coordinator-driven to party-driven
architecture following international MPC system design patterns.
Major changes:
- Add TSS core library (pkg/tss) with keygen and signing protocols
- Implement gRPC clients for Server Party service
- Add MPC session endpoints to Account service
- Deploy 3 Server Party instances in docker-compose
- Add MarkPartyReady and StartSession to proto definitions
- Complete integration tests for 2-of-3, 3-of-5, 4-of-7 thresholds
- Add comprehensive documentation (architecture, API, testing, deployment)
Test results:
- 2-of-3: PASSED (keygen 93s, signing 80s)
- 3-of-5: PASSED (keygen 198s, signing 120s)
- 4-of-7: PASSED (keygen 221s, signing 150s)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
hailin
Developer