feat(notifications): re-generates swagger and sdks

[ygrishajev]

Summary by CodeRabbit

• New Features
  • Added support for two new alert notification types: wallet balance monitoring and chain event detection.
  • Alerts now default to enabled state upon creation, simplifying initial configuration.
  • Restructured alert configuration with improved validation through more granular schema constraints.
  • Enhanced alert response structures with explicit typing for better consistency and reliability.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 46.61%. Comparing base (b819c85) to head (06978f1).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2268      +/-   ##
==========================================
- Coverage   47.64%   46.61%   -1.04%     
==========================================
  Files        1034     1021      -13     
  Lines       29294    28406     -888     
  Branches     7624     7512     -112     
==========================================
- Hits        13957    13241     -716     
+ Misses      14857    14852       -5     
+ Partials      480      313     -167     

Flag	Coverage Δ		*Carryforward flag
api	82.05% <ø> (-0.13%)	⬇️	Carriedforward from 1d1da2c
deploy-web	26.39% <ø> (ø)
log-collector	?
notifications	87.94% <ø> (ø)
provider-console	81.48% <ø> (ø)		Carriedforward from 1d1da2c
provider-proxy	84.47% <ø> (ø)		Carriedforward from 1d1da2c

*This pull request uses carry forward flags. Click here to find out more.
see 233 files with indirect coverage changes

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[coderabbitai]

Walkthrough

The pull request restructures alert-related schemas across the Swagger JSON and React Query SDK by introducing two new notification types (WALLET_BALANCE and CHAIN_EVENT), replacing flat field structures with nested params and conditions objects, adding explicit type discriminators, and tightening field typings for balance-related branches while reorganizing existing alert variants.

Changes

Cohort / File(s)	Summary
Swagger Schema Restructuring apps/notifications/swagger/swagger.json	Extensively restructured Alert-related schemas: replaced flat fields with nested params and complex conditions structures; introduced type enum constraints (CHAIN_MESSAGE, DEPLOYMENT_BALANCE); added default values (enabled: true); reorganized Alert input/output shapes with explicit typing and moved properties into granular nested structures; updated error response schemas for consistency
React Query SDK Schema Extensions packages/react-query-sdk/src/notifications/schema.ts	Added new union branches for WALLET_BALANCE and CHAIN_EVENT notification types; extended AlertCreateInput, AlertOutputResponse, and AlertListOutputResponse with new type variants; tightened field typings for balance-related branches (field: "balance", value: number); introduced params structures for WALLET_BALANCE (owner, denom, suppressedBySystem) and timestamp fields for CHAIN_EVENT variants

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Swagger schema consistency: Verify that all new nested structures (params, conditions) are correctly defined with proper required fields and type constraints across different alert types
• SDK type alignment: Ensure React Query SDK schema definitions precisely mirror the Swagger JSON structure for WALLET_BALANCE and CHAIN_EVENT variants, including field names, types, and optionality
• Type discriminator validation: Confirm that type discriminators (CHAIN_MESSAGE, DEPLOYMENT_BALANCE, WALLET_BALANCE, CHAIN_EVENT) are consistently applied and correctly narrow union types
• Balance field typing: Validate that balance-related conditions and fields are properly constrained (field: "balance", value: number)

Possibly related PRs

• feat(alert): adds alerts name column #1417: Modifies the same alert-related OpenAPI/SDK schemas to support new alert data models and notification types.

Suggested reviewers

• baktun14
• stalniy

Poem

🐰 New alerts hop into place with types so fine,
WALLET_BALANCE, CHAIN_EVENT—nested schemas align.
Params nestled deep, conditions arranged with care,
The rabbit reviewed and found structure fair! ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main purpose of the pull request: regenerating Swagger documentation and SDKs for the notifications feature.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feature/notifications-sdk

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

apps/notifications/swagger/swagger.json (1)

4691-5150: Consider de-duplicating the conditions schema via shared $ref in a follow-up

AlertPatchInput.data.conditions (and the other alert schemas) inline essentially the same nested operator/field/value structure multiple times, with only minor differences between generic and balance-only variants. This is correct but quite verbose and harder to maintain if condition semantics evolve.

If you plan more alert types or condition operators, consider extracting:

• A generic ConditionExpression schema for string/number/boolean fields.
• A BalanceConditionExpression schema for field: "balance" + numeric value.

and then referencing them via $ref in the various oneOf branches. That refactor should happen at the source that emits swagger and be tracked as a separate issue rather than in this regeneration PR.
Based on learnings

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3e91173 and 33e3725.

📒 Files selected for processing (2)

• apps/notifications/swagger/swagger.json (21 hunks)
• packages/react-query-sdk/src/notifications/schema.ts (5 hunks)

🧰 Additional context used

🧠 Learnings (1)

📓 Common learnings

Learnt from: baktun14
Repo: akash-network/console PR: 1725
File: apps/api/src/utils/constants.ts:5-5
Timestamp: 2025-07-24T17:00:52.361Z
Learning: In the Akash Network Console project, when cross-cutting concerns or broader refactoring issues are identified during PR review, the preferred approach is to create a separate GitHub issue to track the work rather than expanding the scope of the current PR. This maintains focus and allows for proper planning of architectural improvements.

🔇 Additional comments (4)

packages/react-query-sdk/src/notifications/schema.ts (2)

247-290: WALLET_BALANCE AlertCreateInput variant looks structurally consistent

The new type: "WALLET_BALANCE" branch mirrors the existing DEPLOYMENT_BALANCE balance-conditions shape (restricted field: "balance" and numeric value) and introduces params with { owner, denom, suppressedBySystem? }, which aligns with the swagger schema and the intended wallet-level semantics. No structural issues stand out here from the SDK consumer perspective.

---

341-387: Output and list unions correctly model CHAIN_EVENT and WALLET_BALANCE variants

The added CHAIN_EVENT and WALLET_BALANCE cases in AlertOutputResponse.data and AlertListOutputResponse.data are internally consistent and match the swagger definitions:

• Each variant has a clear discriminator via type: "CHAIN_MESSAGE" | "CHAIN_EVENT" | "DEPLOYMENT_BALANCE" | "WALLET_BALANCE".
• Balance-based variants (DEPLOYMENT_BALANCE, WALLET_BALANCE) consistently restrict conditions to field: "balance" with value: number.
• params payloads are specialized: deployment balance uses { dseq, owner, suppressedBySystem? }, wallet balance uses { owner, denom, suppressedBySystem? }, while chain-based variants keep the existing { dseq, type, suppressedBySystem? }.

This should give React Query consumers a clean discriminated-union surface over the regenerated API.

Also applies to: 453-487, 557-603, 669-702

apps/notifications/swagger/swagger.json (2)

1121-2211: AlertCreateInput: WALLET_BALANCE and extended alert variants are coherent

Within components.schemas.AlertCreateInput.data.oneOf, the four variants (CHAIN_MESSAGE, CHAIN_EVENT, DEPLOYMENT_BALANCE, WALLET_BALANCE) are well-formed and mutually distinguishable via their type enums. The WALLET balance branch:

• Constrains conditions to numeric balance checks (and/or + single condition).
• Uses params { owner, denom, suppressedBySystem? } with owner and denom required.
• Mirrors the deployment-balance pattern while correctly omitting dseq.

This looks consistent with how the SDK types were generated and should be safe to expose as the canonical contract for creating wallet-balance alerts.

---

2212-4690: AlertOutputResponse & AlertListOutputResponse unions align across all alert types

The new AlertOutputResponse and AlertListOutputResponse schemas correctly:

• Standardize common metadata (notificationChannelId, name, enabled, summary, description, id, userId, status, createdAt, updatedAt).
• Discriminate per-alert behavior via type enums: "CHAIN_MESSAGE" | "CHAIN_EVENT" | "DEPLOYMENT_BALANCE" | "WALLET_BALANCE".
• Keep chain-related branches on generic conditions (field: string, value: string|number|boolean) and optional params { dseq, type, suppressedBySystem? }.
• Restrict balance-based branches to field: "balance" and numeric value, with specialized params for deployment vs wallet.

These shapes match the generated TypeScript in notifications/schema.ts and give clients a predictable discriminated union across list/read/delete responses as well as create.