properly handle app type in api#724
Merged
Merged
Conversation
NoaheCampbell
previously approved these changes
May 17, 2026
divolgin
reviewed
May 18, 2026
| func (c *Client) CreateApp(appOptions interface{}) (interface{}, error) { | ||
| return nil, nil | ||
| switch opts := appOptions.(type) { | ||
| case string: |
Member
There was a problem hiding this comment.
I'm not really sure what this case means. The DeleteApp function handles this differently. But also neither CreateApp nor DeleteApp are used anywhere outside of tests.
Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
marccampbell
force-pushed
the
error-on-app-type
branch
from
e8bdd56 to
c12f109
Compare
divolgin
approved these changes
May 18, 2026
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
problem: The exported aggregate client exposes GetApp, CreateApp, and DeleteApp as successful operations, but they either return a nil result with nil error or a nil error without calling either backend. The context platform client has real CreateApp/DeleteApp implementations, so callers using the higher-level client can believe an app was fetched, created, or deleted when no API request happened. DeleteApp is especially risky because it silently reports success for a no-op.
solution: Implement these methods by delegating to the appropriate platform/KOTS client based on app type or input options. If this abstraction cannot support an operation, return a non-nil unsupported-operation error rather than nil success.