attempt to fix Zai provider not working & model selection not updated #5363
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The Z.ai provider schema was missing support for international_api and china_api endpoints, while the types module already defined all 4 endpoints. This mismatch prevented users from selecting those endpoints in configuration. - Update zaiProviderSchema in core-schemas to include all 4 API line options - Matches the zaiApiLineSchema in packages/types - Existing tests already cover these endpoints
Add comprehensive tests for Z.ai provider configuration in the CLI, covering: - All 4 API endpoints (international_coding, china_coding, international_api, china_api) - All supported GLM models (4.5, 4.6, 4.7) - Required field validation (zaiApiKey, zaiApiLine) - Multiple Z.ai profiles configuration - Integration with CLI config validation Tests verify that the CLI properly validates Z.ai configurations with all available API endpoints and models.
- kc-4h9: verify Z.ai API responses actually being used - kc-9sq: fix CLI status bar showing stale provider info (depends on kc-4h9) Also improve test to verify all 4 valid API line endpoints
…ation - Add request logging to Z.ai handler capturing endpoint, model, tokens, and thinking mode - Add response logging to track reasoning content and response characteristics - Log errors with context (provider, model, endpoint) for debugging - Add GLM-4.7 thinking mode detection and logging - Add 5 new logging tests to existing zai.spec.ts - Add 6 new integration tests in zai-logging.integration.spec.ts - Add ZAI_LOGGING.md documentation for verification procedures - All 44 Z.ai tests pass (38 original + 6 new) - Verifies: correct endpoint, auth headers, request params, response parsing Fixes: kc-4h9
…t (kc-9sq) Fixes issue where CLI status bar would continue showing old provider/model info after user selected a new provider via /provider select command. Root cause: After upsertApiConfiguration message was processed by extension, the updated state was not being sent back to CLI immediately. Now postStateToWebview() is called unconditionally to ensure state is synced, allowing apiConfigurationAtom to be updated and status bar to reflect the new provider/model selection. Changes: - Modified webviewMessageHandler.ts to always call postStateToWebview() after upsertApiConfiguration is processed (wrapped in try-catch for error handling) - Updated error test to provide complete mocks for upsertApiConfiguration handler - Added integration test to verify provider selection status updates immediately - Added unit test to StatusBar to verify it updates when apiConfiguration changes This ensures the CLI status bar immediately reflects provider changes without requiring manual refresh, improving user experience when switching providers. Underlying API calls were already using the correct provider (verified in kc-4h9), this fix only addresses the UI display synchronization issue.
🦋 Changeset detectedLatest commit: a206b30 The changes in this PR will be included in the next version bump. This PR includes changesets to release 4 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Author
|
Marked as draft because this doesn't yet fix the problem. Hopefully someone reviewing the work can see what's missing (e.g. please don't ignore because it's in draft). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What Was Attempted
Three-layered fix approach for the CLI status bar not updating after /provider select, #5351
Quality Gates ✓
2102 CLI tests passing
233 webview tests passing
TypeScript checks passing
ESLint passing
No empty catch blocks
Integration test added: provider-selection-status-update.integration.test.ts
Why It Didn't Resolve the Issue
The fix is architecturally sound but doesn't solve the problem. Root cause likely involves one of:
Cache-first pattern in getModels() preventing fresh data
State sync timing issue between profile save and state read
Provider name transformation issues
StatusBar component's model lookup logic
Documentation Provided
PR_ATTEMPT_SUMMARY.md - Detailed technical analysis of approaches and suspected issues
Code comments with kilocode_change markers for upstream merge tracking
Test coverage showing expected behavior
The branch is ready for someone with logging capability and test environment access to continue debugging. All changes are documented and code quality standards believed to be met.
Work done by Ampcode in free mode (so using Claude Sonnet 4.5)