Skip to content
This repository was archived by the owner on Jun 11, 2025. It is now read-only.

🎨 Remove omitempty from app_type(hpa.enabled)#288

Merged
abdheshnayak merged 1 commit into
update/publish-natsfrom
improve/app_type
Mar 5, 2024
Merged

🎨 Remove omitempty from app_type(hpa.enabled)#288
abdheshnayak merged 1 commit into
update/publish-natsfrom
improve/app_type

Conversation

@abdheshnayak
Copy link
Copy Markdown
Contributor

No description provided.

@abdheshnayak abdheshnayak merged commit 577d727 into update/publish-nats Mar 5, 2024
@abdheshnayak abdheshnayak deleted the improve/app_type branch March 5, 2024 11:57
Copy link
Copy Markdown

@sourcery-ai sourcery-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey abdheshnayak - Here's my review!

General suggestions:

  • Ensure that the new 'isReadyOnly' resolver's implementation is completed and properly integrated into the system.
  • Review the impact of making the 'enabled' field non-optional on existing data and client interactions to ensure backward compatibility.
  • Consider the broader implications of these changes on the system's functionality and user experience.

Thanks for using Sourcery. We offer it for free for open source projects and would be very grateful if you could help us grow. If you like it, would you consider sharing Sourcery on your favourite social media? ✨

Share Sourcery

Help me be more useful! Please click 👍 or 👎 on each comment to tell me if it was helpful.


return e.complexity.Secret.Immutable(childComplexity), true

case "Secret.isReadyOnly":
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion (llm): Given the addition of the IsReadyOnly field in the GraphQL schema, it's important to ensure that integration tests are updated or added to cover this new field. This includes testing the field's behavior in queries and mutations where it's applicable, ensuring that the field behaves as expected in different scenarios, including edge cases.

MinReplicas *int `json:"minReplicas,omitempty"`
ThresholdCPU *int `json:"thresholdCpu,omitempty"`
ThresholdMemory *int `json:"thresholdMemory,omitempty"`
Enabled bool `json:"enabled"`
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue (llm): The removal of omitempty from the enabled field in the HPA model indicates a significant change in how the absence of a value is treated. It's essential to add or update unit tests for any serialization/deserialization logic that involves these models to ensure that the absence of the enabled field is handled as expected. Additionally, consider adding tests that verify the API's behavior when the enabled field is not provided by the client, ensuring backward compatibility and clear error messaging.

abdheshnayak added a commit that referenced this pull request Nov 5, 2024
🎨 Remove omitempty from app_type(hpa.enabled)
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant