feat: schema changes + ci fix#27
Conversation
📝 WalkthroughWalkthroughThis PR restructures yield risk data modeling from flat parameter objects to hierarchical DTOs with staking rewards support, introduces yield campaign management endpoints and types, updates CI infrastructure with pinned actions and tool versions, and removes deprecated RiskParameterDto types. ChangesYield Risk & Campaign API Expansion
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 11
🧹 Nitpick comments (3)
src/api/schemas/yieldRiskStakingRewardsMetricsDtoUsers.ts (1)
4-4: ⚡ Quick winTighten
usersmetric value typing to numeric values.On Line 4, using
unknownfor a “users count” field makes the DTO hard to consume safely. Prefer a numeric map type so callers get useful type-checking.Proposed change
-export type YieldRiskStakingRewardsMetricsDtoUsers = { [key: string]: unknown }; +export type YieldRiskStakingRewardsMetricsDtoUsers = Record<string, number>;🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/api/schemas/yieldRiskStakingRewardsMetricsDtoUsers.ts` at line 4, The current DTO type YieldRiskStakingRewardsMetricsDtoUsers uses unknown for values which prevents safe consumption; change its definition to map string keys to numeric values (e.g., use Record<string, number> or { [key: string]: number }) so callers get compile-time guarantees that each users metric is a number and can be safely operated on.src/api/schemas/yieldsControllerGetYieldCampaigns200.ts (1)
4-5: ⚡ Quick winConsider making
itemsrequired if the 200 contract always returns a list.Using
items: YieldCampaignDto[](empty array when no results) simplifies downstream handling and keeps pagination responses stricter.Proposed tweak
export type YieldsControllerGetYieldCampaigns200 = PaginatedResponseDto & { - items?: YieldCampaignDto[]; + items: YieldCampaignDto[]; };🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/api/schemas/yieldsControllerGetYieldCampaigns200.ts` around lines 4 - 5, The response type YieldsControllerGetYieldCampaigns200 currently makes items optional; change its items?: YieldCampaignDto[] to a required items: YieldCampaignDto[] so the 200 contract always returns an array (empty when no results). Update any places that construct or return YieldsControllerGetYieldCampaigns200 (factory/mapper/handler functions) to ensure they provide an empty [] instead of undefined, and run type-checks to fix any call sites expecting items to be optional.src/api/index.ts (1)
87-99: Call outgetYieldRiskresponse-shape change in release notes/versioning.This switches consumers from the previous risk-params array contract to
YieldRiskDto; make sure the SDK release communication and semver strategy explicitly reflect that.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/api/index.ts` around lines 87 - 99, Update release notes and versioning to explicitly call out the response-shape change introduced by getYieldRisk: it now returns YieldRiskDto instead of the previous risk-params array contract; mention the API contract change in the changelog and bump the SDK version per your semver policy (e.g., major or minor) so consumers of customFetch and getYieldRisk can prepare for the breaking/behavioral change.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/ci.yml:
- Around line 19-21: The PATH updates appended to $GITHUB_PATH won't take effect
until the next step, so before calling mise install add an inline PATH export
that prepends $HOME/.local/share/mise/bin and $HOME/.local/share/mise/shims to
PATH so mise is available immediately, then still append those two paths to
$GITHUB_PATH (the existing echo lines) so they persist for subsequent steps;
update the step that runs mise to perform the inline export before invoking the
mise command.
- Line 18: The workflow currently runs an unverified remote installer via the
line "curl https://mise.run | sh", which is a supply-chain risk; replace that
step with the official GitHub Action "jdx/mise-action" and pin it to a full
commit SHA (not a tag) in the workflow invocation, or, if you must keep the
installer, add proper GPG signature verification per the mise docs; update the
step that contains the "curl https://mise.run | sh" command to use the pinned
action reference or include signature verification logic instead.
In `@src/api/index.msw.ts`:
- Around line 11103-11316: The timestamps for campaigns are sampled
independently which can produce impossible timelines; instead generate a base
startTime (e.g., const start = faker.date.past()), then compute endTime =
faker.date.between(start, someLaterDate) and derive dependent fields:
lastProcessedHour (nullable) must be between start and end (or null),
nextPayoutDueAt (nullable) must be >= lastProcessedHour (when present) and <=
end, and any other time fields (createdAt, updatedAt) should be consistent
relative to start/end; update the code that sets startTime, endTime,
lastProcessedHour, nextPayoutDueAt (and related fields) to use these derived
values and preserve existing randomness for nullability and status handling.
In `@src/api/schemas/yieldRiskStakingRewardsDtoChain.ts`:
- Line 4: The exported type YieldRiskStakingRewardsDtoChain currently allows
arbitrary unknown values; change it so each chain key maps to a string label
instead of unknown objects — update the type definition for
YieldRiskStakingRewardsDtoChain to be a mapping from string keys to string
values (i.e., value type should be string) so callers treat chain entries as
label strings.
In `@src/api/schemas/yieldRiskStakingRewardsDtoProviderName.ts`:
- Line 4: The type YieldRiskStakingRewardsDtoProviderName currently allows any
object ({ [key: string]: unknown }) but should be a string alias; update the
type declaration for YieldRiskStakingRewardsDtoProviderName to be a string
(e.g., export type YieldRiskStakingRewardsDtoProviderName = string) and update
any locations that import or use YieldRiskStakingRewardsDtoProviderName to
expect a string (or a tighter string literal/union if desired) so validation and
typings reflect a provider name string.
In `@src/api/schemas/yieldRiskStakingRewardsDtoRatedSince.ts`:
- Line 4: The exported type YieldRiskStakingRewardsDtoRatedSince is currently an
open object; change it to a date-string type to enforce the DTO contract by
replacing the index-signature with a string alias (e.g., export type
YieldRiskStakingRewardsDtoRatedSince = string) and document/validate it as an
ISO-8601 date where the type is consumed (update any validators, tests, or
parsers that assumed an object). Ensure any code expecting a mapped object uses
the new string type or adapts to read a date string (and add
conversion/validation in functions that parse ratedSince).
In `@src/api/schemas/yieldRiskStakingRewardsDtoRating.ts`:
- Around line 1-4: Replace the permissive index-signature in
YieldRiskStakingRewardsDtoRating and the related files with explicit typed
properties matching the JSDoc: define YieldRiskStakingRewardsDtoRating as an
object with specific fields (e.g., score: number (1-5), potentialScore?: number
(1-5), ratedAt?: string (ISO date), ratedSince?: string (ISO date), profileUrl?:
string, reportUrl?: string, contractAddress?: string, potentialRating?: {...}
same shape as rating, version?: string, type?: string, providerName?: string,
chain?: string); change the separate files: YieldRiskStakingRewardsDtoScore and
YieldRiskStakingRewardsDtoPotentialScore to number,
YieldRiskStakingRewardsDtoRatedAt and RatedSince to string,
ProfileUrl/ReportUrl/ContractAddress/Version/Type/ProviderName/Chain to string,
and ensure the rating/potentialRating types reference the new specific rating
interface so IDEs and the compiler validate structure rather than allowing
{[key:string]: unknown}.
In `@src/api/schemas/yieldRiskStakingRewardsDtoReportUrl.ts`:
- Line 4: The current broad index signature in the exported type
YieldRiskStakingRewardsDtoReportUrl should be replaced with an explicit URL
scalar property to enforce type safety: change the type to require a reportUrl
field (e.g., reportUrl: string or your project’s URL scalar type) instead of {
[key: string]: unknown }, update any serializers/validators that consume
YieldRiskStakingRewardsDtoReportUrl to validate/parse the URL value, and ensure
all usages of YieldRiskStakingRewardsDtoReportUrl (constructors, mappers, tests)
are updated to pass a reportUrl property.
In `@src/api/schemas/yieldRiskStakingRewardsDtoScore.ts`:
- Line 4: Replace the open-object type for YieldRiskStakingRewardsDtoScore with
a bounded numeric type so it only allows the integers 1 through 5; locate the
type alias YieldRiskStakingRewardsDtoScore and change its definition from a
generic {[key: string]: unknown} to a union of the allowed integer literals
(1,2,3,4,5) or an equivalent branded/validated numeric type so compile-time
typing enforces the 1–5 range.
In `@src/api/schemas/yieldRiskStakingRewardsDtoType.ts`:
- Line 4: The DTO currently declares YieldRiskStakingRewardsDtoType as a loose
object ({ [key: string]: unknown }) which allows arbitrary shapes; change it to
a scalar discriminator (e.g., a plain string or a string literal union/enum) so
the product type is a single scalar value. Update the declaration of
YieldRiskStakingRewardsDtoType to a scalar type (or a string enum of allowed
product types), and adjust any validation/serialization code and places that
import/use YieldRiskStakingRewardsDtoType to expect a scalar product type
instead of an object.
In `@src/api/schemas/yieldRiskStakingRewardsDtoVersion.ts`:
- Line 4: The exported type YieldRiskStakingRewardsDtoVersion is currently a
catch-all object ({ [key: string]: unknown }) but should be a scalar version
token; change the type definition of YieldRiskStakingRewardsDtoVersion from an
open object to an appropriate scalar (e.g., string or a narrow union of allowed
tokens) and update any validators or usages that expect a version token to
reflect the new scalar type so DTO correctness is restored.
---
Nitpick comments:
In `@src/api/index.ts`:
- Around line 87-99: Update release notes and versioning to explicitly call out
the response-shape change introduced by getYieldRisk: it now returns
YieldRiskDto instead of the previous risk-params array contract; mention the API
contract change in the changelog and bump the SDK version per your semver policy
(e.g., major or minor) so consumers of customFetch and getYieldRisk can prepare
for the breaking/behavioral change.
In `@src/api/schemas/yieldRiskStakingRewardsMetricsDtoUsers.ts`:
- Line 4: The current DTO type YieldRiskStakingRewardsMetricsDtoUsers uses
unknown for values which prevents safe consumption; change its definition to map
string keys to numeric values (e.g., use Record<string, number> or { [key:
string]: number }) so callers get compile-time guarantees that each users metric
is a number and can be safely operated on.
In `@src/api/schemas/yieldsControllerGetYieldCampaigns200.ts`:
- Around line 4-5: The response type YieldsControllerGetYieldCampaigns200
currently makes items optional; change its items?: YieldCampaignDto[] to a
required items: YieldCampaignDto[] so the 200 contract always returns an array
(empty when no results). Update any places that construct or return
YieldsControllerGetYieldCampaigns200 (factory/mapper/handler functions) to
ensure they provide an empty [] instead of undefined, and run type-checks to fix
any call sites expecting items to be optional.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: af6bf88c-f56e-4efb-8bad-f844b1b74c35
📒 Files selected for processing (45)
.github/workflows/ci.ymlmise.tomlsrc/api/index.msw.tssrc/api/index.tssrc/api/schemas/campaignPayoutFrequency.tssrc/api/schemas/campaignQualificationConfigDto.tssrc/api/schemas/campaignQualificationType.tssrc/api/schemas/campaignRewardMode.tssrc/api/schemas/campaignStatus.tssrc/api/schemas/index.tssrc/api/schemas/networks.tssrc/api/schemas/rewardDtoYieldSource.tssrc/api/schemas/riskParameterDto.tssrc/api/schemas/riskParameterDtoAsset.tssrc/api/schemas/riskParameterDtoIntegrationId.tssrc/api/schemas/riskParameterDtoProtocol.tssrc/api/schemas/riskParameterDtoValue.tssrc/api/schemas/yieldCampaignDto.tssrc/api/schemas/yieldDto.tssrc/api/schemas/yieldRiskDto.tssrc/api/schemas/yieldRiskEntryDto.tssrc/api/schemas/yieldRiskEntryDtoSource.tssrc/api/schemas/yieldRiskStakingRewardsDto.tssrc/api/schemas/yieldRiskStakingRewardsDtoChain.tssrc/api/schemas/yieldRiskStakingRewardsDtoContractAddress.tssrc/api/schemas/yieldRiskStakingRewardsDtoPotentialRating.tssrc/api/schemas/yieldRiskStakingRewardsDtoPotentialScore.tssrc/api/schemas/yieldRiskStakingRewardsDtoProfileUrl.tssrc/api/schemas/yieldRiskStakingRewardsDtoProviderName.tssrc/api/schemas/yieldRiskStakingRewardsDtoRatedAt.tssrc/api/schemas/yieldRiskStakingRewardsDtoRatedSince.tssrc/api/schemas/yieldRiskStakingRewardsDtoRating.tssrc/api/schemas/yieldRiskStakingRewardsDtoReportUrl.tssrc/api/schemas/yieldRiskStakingRewardsDtoScore.tssrc/api/schemas/yieldRiskStakingRewardsDtoType.tssrc/api/schemas/yieldRiskStakingRewardsDtoVersion.tssrc/api/schemas/yieldRiskStakingRewardsMetricsDto.tssrc/api/schemas/yieldRiskStakingRewardsMetricsDtoUsers.tssrc/api/schemas/yieldRiskSummaryDto.tssrc/api/schemas/yieldsControllerGetYieldCampaigns200.tssrc/api/schemas/yieldsControllerGetYieldCampaigns400.tssrc/api/schemas/yieldsControllerGetYieldCampaigns401.tssrc/api/schemas/yieldsControllerGetYieldCampaigns429.tssrc/api/schemas/yieldsControllerGetYieldCampaigns500.tssrc/api/schemas/yieldsControllerGetYieldCampaignsParams.ts
💤 Files with no reviewable changes (5)
- src/api/schemas/riskParameterDto.ts
- src/api/schemas/riskParameterDtoProtocol.ts
- src/api/schemas/riskParameterDtoValue.ts
- src/api/schemas/riskParameterDtoAsset.ts
- src/api/schemas/riskParameterDtoIntegrationId.ts
| - uses: jdx/mise-action@v2 | ||
| - name: Install mise | ||
| run: | | ||
| curl https://mise.run | sh |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is the recommended secure way to install mise in GitHub Actions: pinned jdx/mise-action commit SHA or checksum-verified installer script?
💡 Result:
Recommended secure approach: pin jdx/mise-action to a full commit SHA (not a tag), and avoid the unauthenticated “curl | sh” style installer unless you verify its signature/checksum. In addition, use mise.lock (checksum-verified tool tarballs) to ensure the exact mise-installed tools are reproducible. 1) Pin the GitHub Action to a commit SHA - GitHub recommends pinning third-party Actions to a specific commit SHA to prevent malicious code in newly-updated branches/tags from being used automatically. [1] - Example: - uses: jdx/mise-action@ 2) Prefer mise-action for installing mise/tools in CI - The supported GitHub Actions integration for mise is jdx/mise-action, which installs mise and runs mise install/tool installation according to your configuration. [2][3] 3) If you use the installer script, verify it (signature or checksum), not just curl|sh - The mise install documentation provides an explicit verification flow using GPG: download install.sh and decrypt the detached signature install.sh.sig, verify it was signed by the mise release key, then run the script. [4][5] - The documentation also notes that without changing MISE_VERSION, the script is pinned to “whatever the latest version was when it was downloaded with checksums inside the file,” i.e., the checksum logic inside the script governs what it installs. [4] 4) Use mise.lock for checksum verification of tool tarballs - mise supports lockfiles that “store/verify the checksum of tool tarballs,” and committing mise.lock helps ensure the exact same tool versions are installed across developers and CI/CD systems. [6] Which is more secure: pinned SHA vs checksum-verified installer? - For the Action itself: pinning to a commit SHA is the strongest control against supply-chain changes in the Action code, and is explicitly recommended by GitHub. [1] - For installing the mise binary via script: checksum/signature verification is the secure counterpart when you choose the script-based route. [4][5] So the “secure best practice” stack is: - Pin jdx/mise-action to a full commit SHA for CI governance. [1] - Use mise.lock to checksum-verify the installed tools. [6] - Only if you must use the script, verify its signature/checksum as documented. [4][5] Sample hardened workflow snippet (using mise-action): - uses: jdx/mise-action@c94f0bf # example full SHA pin from jdx/mise repo history with: version: 2026.3.10 install: true cache: true # plus your tool_versions/mise_toml Confidence: high that SHA-pinning and script signature verification are correct because they are explicitly stated in GitHub’s recommendation and mise’s own docs, and mise.lock checksum verification is explicitly described in mise security documentation. [1][4][5][6]
Citations:
- 1: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
- 2: https://mise.en.dev/continuous-integration.html
- 3: https://github.com/jdx/mise/blob/5be2b8fd/docs/continuous-integration.md
- 4: https://github.com/jdx/mise/blob/30996304/docs/installing-mise.md
- 5: https://mise.en.dev/installing-mise.html
- 6: https://github.com/jdxcode/rtx/blob/main/SECURITY.md
Replace curl | sh with jdx/mise-action GitHub Action pinned to a commit SHA.
Line 18 executes a remote installer script without integrity verification, creating a supply-chain risk. Use the official jdx/mise-action Action pinned to a full commit SHA (not a tag) instead, or if you must use the installer script, verify it with GPG signature as documented in the mise installation guide.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci.yml at line 18, The workflow currently runs an
unverified remote installer via the line "curl https://mise.run | sh", which is
a supply-chain risk; replace that step with the official GitHub Action
"jdx/mise-action" and pin it to a full commit SHA (not a tag) in the workflow
invocation, or, if you must keep the installer, add proper GPG signature
verification per the mise docs; update the step that contains the "curl
https://mise.run | sh" command to use the pinned action reference or include
signature verification logic instead.
| echo "$HOME/.local/share/mise/bin" >> $GITHUB_PATH | ||
| echo "$HOME/.local/share/mise/shims" >> $GITHUB_PATH | ||
| mise install |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
GitHub Actions documentation: when writing to GITHUB_PATH inside a run step, is the updated PATH available in the same step or only subsequent steps?
💡 Result:
When writing to GITHUB_PATH inside a run step in GitHub Actions, the updated PATH is not available in the same step. It is only available to subsequent steps in the same job.[1][2]
Citations:
- 1: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-commands
- 2: https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions
Fix PATH updates before using mise install in the same step.
Line 21 uses mise in the same step where lines 19-20 append to $GITHUB_PATH, but GitHub Actions environment variable exports don't apply until the next step. Use inline export PATH to make the directories available immediately, then append to $GITHUB_PATH for subsequent steps.
Suggested patch
- name: Install mise
run: |
- curl https://mise.run | sh
- echo "$HOME/.local/share/mise/bin" >> $GITHUB_PATH
- echo "$HOME/.local/share/mise/shims" >> $GITHUB_PATH
- mise install
+ set -euo pipefail
+ curl -fsSL https://mise.run | sh
+ export PATH="$HOME/.local/bin:$HOME/.local/share/mise/bin:$HOME/.local/share/mise/shims:$PATH"
+ echo "$HOME/.local/bin" >> "$GITHUB_PATH"
+ echo "$HOME/.local/share/mise/bin" >> "$GITHUB_PATH"
+ echo "$HOME/.local/share/mise/shims" >> "$GITHUB_PATH"
+ mise install🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci.yml around lines 19 - 21, The PATH updates appended to
$GITHUB_PATH won't take effect until the next step, so before calling mise
install add an inline PATH export that prepends $HOME/.local/share/mise/bin and
$HOME/.local/share/mise/shims to PATH so mise is available immediately, then
still append those two paths to $GITHUB_PATH (the existing echo lines) so they
persist for subsequent steps; update the step that runs mise to perform the
inline export before invoking the mise command.
| createdAt: faker.date.past().toISOString().slice(0, 19) + "Z", | ||
| updatedAt: faker.date.past().toISOString().slice(0, 19) + "Z", | ||
| yieldId: faker.string.alpha({ length: { min: 10, max: 20 } }), | ||
| status: faker.helpers.arrayElement(Object.values(CampaignStatus)), | ||
| rewardMode: faker.helpers.arrayElement( | ||
| Object.values(CampaignRewardMode), | ||
| ), | ||
| rewardRate: { | ||
| ...{ | ||
| total: faker.number.float({ fractionDigits: 2 }), | ||
| rateType: faker.string.alpha({ length: { min: 10, max: 20 } }), | ||
| components: Array.from( | ||
| { length: faker.number.int({ min: 1, max: 10 }) }, | ||
| (_, i) => i + 1, | ||
| ).map(() => ({ | ||
| rate: faker.number.float({ fractionDigits: 2 }), | ||
| rateType: faker.string.alpha({ length: { min: 10, max: 20 } }), | ||
| token: { | ||
| ...{ | ||
| symbol: faker.string.alpha({ | ||
| length: { min: 10, max: 20 }, | ||
| }), | ||
| name: faker.string.alpha({ length: { min: 10, max: 20 } }), | ||
| decimals: faker.number.float({ fractionDigits: 2 }), | ||
| network: faker.helpers.arrayElement([ | ||
| "ethereum", | ||
| "ethereum-goerli", | ||
| "ethereum-holesky", | ||
| "ethereum-sepolia", | ||
| "ethereum-hoodi", | ||
| "arbitrum", | ||
| "base", | ||
| "base-sepolia", | ||
| "gnosis", | ||
| "optimism", | ||
| "polygon", | ||
| "polygon-amoy", | ||
| "starknet", | ||
| "zksync", | ||
| "linea", | ||
| "unichain", | ||
| "monad-testnet", | ||
| "monad", | ||
| "avalanche-c", | ||
| "avalanche-c-atomic", | ||
| "avalanche-p", | ||
| "binance", | ||
| "celo", | ||
| "fantom", | ||
| "harmony", | ||
| "moonriver", | ||
| "okc", | ||
| "viction", | ||
| "core", | ||
| "sonic", | ||
| "plasma", | ||
| "katana", | ||
| "hyperevm", | ||
| "agoric", | ||
| "akash", | ||
| "axelar", | ||
| "band-protocol", | ||
| "bitsong", | ||
| "canto", | ||
| "chihuahua", | ||
| "comdex", | ||
| "coreum", | ||
| "cosmos", | ||
| "crescent", | ||
| "cronos", | ||
| "cudos", | ||
| "desmos", | ||
| "dydx", | ||
| "evmos", | ||
| "fetch-ai", | ||
| "gravity-bridge", | ||
| "injective", | ||
| "irisnet", | ||
| "juno", | ||
| "kava", | ||
| "ki-network", | ||
| "mars-protocol", | ||
| "nym", | ||
| "okex-chain", | ||
| "onomy", | ||
| "osmosis", | ||
| "persistence", | ||
| "quicksilver", | ||
| "regen", | ||
| "secret", | ||
| "sentinel", | ||
| "sommelier", | ||
| "stafi", | ||
| "stargaze", | ||
| "stride", | ||
| "teritori", | ||
| "tgrade", | ||
| "umee", | ||
| "sei", | ||
| "mantra", | ||
| "celestia", | ||
| "saga", | ||
| "zetachain", | ||
| "dymension", | ||
| "humansai", | ||
| "neutron", | ||
| "polkadot", | ||
| "kusama", | ||
| "westend", | ||
| "bittensor", | ||
| "aptos", | ||
| "binancebeacon", | ||
| "cardano", | ||
| "near", | ||
| "solana", | ||
| "solana-devnet", | ||
| "stellar", | ||
| "stellar-testnet", | ||
| "sui", | ||
| "tezos", | ||
| "tron", | ||
| "ton", | ||
| "ton-testnet", | ||
| "hyperliquid", | ||
| ] as const), | ||
| address: faker.helpers.arrayElement([ | ||
| faker.string.alpha({ length: { min: 10, max: 20 } }), | ||
| undefined, | ||
| ]), | ||
| logoURI: faker.helpers.arrayElement([ | ||
| faker.string.alpha({ length: { min: 10, max: 20 } }), | ||
| undefined, | ||
| ]), | ||
| isPoints: faker.helpers.arrayElement([ | ||
| faker.datatype.boolean(), | ||
| undefined, | ||
| ]), | ||
| coinGeckoId: faker.helpers.arrayElement([ | ||
| faker.string.alpha({ length: { min: 10, max: 20 } }), | ||
| undefined, | ||
| ]), | ||
| }, | ||
| }, | ||
| yieldSource: faker.helpers.arrayElement([ | ||
| "staking", | ||
| "restaking", | ||
| "protocol_incentive", | ||
| "campaign_incentive", | ||
| "points", | ||
| "lending", | ||
| "mev", | ||
| "real_world_asset_yield", | ||
| "vault", | ||
| ] as const), | ||
| description: faker.helpers.arrayElement([ | ||
| faker.string.alpha({ length: { min: 10, max: 20 } }), | ||
| undefined, | ||
| ]), | ||
| })), | ||
| }, | ||
| }, | ||
| totalBudget: faker.string.alpha({ length: { min: 10, max: 20 } }), | ||
| distributedBudget: faker.string.alpha({ | ||
| length: { min: 10, max: 20 }, | ||
| }), | ||
| remainingBudget: faker.string.alpha({ length: { min: 10, max: 20 } }), | ||
| configuredHourlyEmission: faker.helpers.arrayElement([ | ||
| faker.helpers.arrayElement([ | ||
| faker.string.alpha({ length: { min: 10, max: 20 } }), | ||
| null, | ||
| ]), | ||
| undefined, | ||
| ]), | ||
| apyCeiling: faker.helpers.arrayElement([ | ||
| faker.helpers.arrayElement([ | ||
| faker.number.float({ fractionDigits: 2 }), | ||
| null, | ||
| ]), | ||
| undefined, | ||
| ]), | ||
| qualificationConfig: { | ||
| ...{ | ||
| type: faker.helpers.arrayElement( | ||
| Object.values(CampaignQualificationType), | ||
| ), | ||
| threshold: faker.string.alpha({ length: { min: 10, max: 20 } }), | ||
| maxIncentivizedTvlToken: faker.helpers.arrayElement([ | ||
| faker.helpers.arrayElement([ | ||
| faker.string.alpha({ length: { min: 10, max: 20 } }), | ||
| null, | ||
| ]), | ||
| undefined, | ||
| ]), | ||
| }, | ||
| }, | ||
| startTime: faker.date.past().toISOString().slice(0, 19) + "Z", | ||
| endTime: faker.date.past().toISOString().slice(0, 19) + "Z", | ||
| lastProcessedHour: faker.helpers.arrayElement([ | ||
| faker.helpers.arrayElement([ | ||
| faker.date.past().toISOString().slice(0, 19) + "Z", | ||
| null, | ||
| ]), | ||
| undefined, | ||
| ]), | ||
| nextPayoutDueAt: faker.helpers.arrayElement([ | ||
| faker.helpers.arrayElement([ | ||
| faker.date.past().toISOString().slice(0, 19) + "Z", | ||
| null, | ||
| ]), | ||
| undefined, | ||
| ]), | ||
| payoutFrequency: faker.helpers.arrayElement( | ||
| Object.values(CampaignPayoutFrequency), | ||
| ), |
There was a problem hiding this comment.
Keep the campaign timeline internally consistent.
Line 11103 through Line 11316 samples all campaign timestamps independently, so this mock can generate impossible states like endTime < startTime or nextPayoutDueAt < lastProcessedHour. That makes tests and stories using the new campaigns endpoint brittle, especially when status is also randomized separately.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/api/index.msw.ts` around lines 11103 - 11316, The timestamps for
campaigns are sampled independently which can produce impossible timelines;
instead generate a base startTime (e.g., const start = faker.date.past()), then
compute endTime = faker.date.between(start, someLaterDate) and derive dependent
fields: lastProcessedHour (nullable) must be between start and end (or null),
nextPayoutDueAt (nullable) must be >= lastProcessedHour (when present) and <=
end, and any other time fields (createdAt, updatedAt) should be consistent
relative to start/end; update the code that sets startTime, endTime,
lastProcessedHour, nextPayoutDueAt (and related fields) to use these derived
values and preserve existing randomness for nullability and status handling.
| /** | ||
| * Chain label returned by Staking Rewards | ||
| */ | ||
| export type YieldRiskStakingRewardsDtoChain = { [key: string]: unknown }; |
There was a problem hiding this comment.
Type chain as a label string
Line 4 currently allows arbitrary objects for a field documented as a chain label.
Proposed fix
-export type YieldRiskStakingRewardsDtoChain = { [key: string]: unknown };
+export type YieldRiskStakingRewardsDtoChain = string;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export type YieldRiskStakingRewardsDtoChain = { [key: string]: unknown }; | |
| export type YieldRiskStakingRewardsDtoChain = string; |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/api/schemas/yieldRiskStakingRewardsDtoChain.ts` at line 4, The exported
type YieldRiskStakingRewardsDtoChain currently allows arbitrary unknown values;
change it so each chain key maps to a string label instead of unknown objects —
update the type definition for YieldRiskStakingRewardsDtoChain to be a mapping
from string keys to string values (i.e., value type should be string) so callers
treat chain entries as label strings.
| /** | ||
| * Staking Rewards provider name | ||
| */ | ||
| export type YieldRiskStakingRewardsDtoProviderName = { [key: string]: unknown }; |
There was a problem hiding this comment.
providerName should be a string alias
Line 4 currently permits arbitrary object payloads for a field documented as a provider name.
Proposed fix
-export type YieldRiskStakingRewardsDtoProviderName = { [key: string]: unknown };
+export type YieldRiskStakingRewardsDtoProviderName = string;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export type YieldRiskStakingRewardsDtoProviderName = { [key: string]: unknown }; | |
| export type YieldRiskStakingRewardsDtoProviderName = string; |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/api/schemas/yieldRiskStakingRewardsDtoProviderName.ts` at line 4, The
type YieldRiskStakingRewardsDtoProviderName currently allows any object ({ [key:
string]: unknown }) but should be a string alias; update the type declaration
for YieldRiskStakingRewardsDtoProviderName to be a string (e.g., export type
YieldRiskStakingRewardsDtoProviderName = string) and update any locations that
import or use YieldRiskStakingRewardsDtoProviderName to expect a string (or a
tighter string literal/union if desired) so validation and typings reflect a
provider name string.
| /** | ||
| * Staking Rewards rating | ||
| */ | ||
| export type YieldRiskStakingRewardsDtoRating = { [key: string]: unknown }; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for OpenAPI spec or API schema definitions
echo "=== Searching for OpenAPI/Swagger specs ==="
fd -e json -e yaml -e yml openapi swagger api-spec
echo -e "\n=== Checking for schema generation config ==="
fd -e json -e js -e ts orval openapi-generator api-codegen
echo -e "\n=== Searching for existing YieldRiskStakingRewardsDto usage ==="
rg -n "YieldRiskStakingRewardsDto" --type=ts -C 3Repository: stakekit/sdk
Length of output: 11233
Define specific types for StakingRewards DTO properties instead of using permissive index signatures.
The pattern { [key: string]: unknown } appears across 13+ type files in the StakingRewards schema, defeating TypeScript's type safety. Despite JSDoc comments describing specific semantics (e.g., "score (1-5)", "Date when rating was assessed", "profile URL"), the types accept any object shape.
Affected files:
yieldRiskStakingRewardsDtoRating.ts→ should be a specific rating structureyieldRiskStakingRewardsDtoScore.ts→ should benumber(1-5 range)yieldRiskStakingRewardsDtoPotentialScore.ts→ should benumber(1-5 range)yieldRiskStakingRewardsDtoRatedAt.ts→ should bestring(ISO date)yieldRiskStakingRewardsDtoRatedSince.ts→ should bestring(ISO date)yieldRiskStakingRewardsDtoProfileUrl.ts→ should bestringyieldRiskStakingRewardsDtoReportUrl.ts→ should bestringyieldRiskStakingRewardsDtoContractAddress.ts→ should bestringyieldRiskStakingRewardsDtoPotentialRating.ts→ should be a specific rating structureyieldRiskStakingRewardsDtoVersion.ts→ should bestringyieldRiskStakingRewardsDtoType.ts→ should bestringyieldRiskStakingRewardsDtoProviderName.ts→ should bestringyieldRiskStakingRewardsDtoChain.ts→ should bestring
This eliminates compile-time validation, IDE autocomplete, and allows runtime type errors. Replace the index signatures with proper types reflecting the semantics documented in JSDoc comments.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/api/schemas/yieldRiskStakingRewardsDtoRating.ts` around lines 1 - 4,
Replace the permissive index-signature in YieldRiskStakingRewardsDtoRating and
the related files with explicit typed properties matching the JSDoc: define
YieldRiskStakingRewardsDtoRating as an object with specific fields (e.g., score:
number (1-5), potentialScore?: number (1-5), ratedAt?: string (ISO date),
ratedSince?: string (ISO date), profileUrl?: string, reportUrl?: string,
contractAddress?: string, potentialRating?: {...} same shape as rating,
version?: string, type?: string, providerName?: string, chain?: string); change
the separate files: YieldRiskStakingRewardsDtoScore and
YieldRiskStakingRewardsDtoPotentialScore to number,
YieldRiskStakingRewardsDtoRatedAt and RatedSince to string,
ProfileUrl/ReportUrl/ContractAddress/Version/Type/ProviderName/Chain to string,
and ensure the rating/potentialRating types reference the new specific rating
interface so IDEs and the compiler validate structure rather than allowing
{[key:string]: unknown}.
| /** | ||
| * Staking Rewards full report URL | ||
| */ | ||
| export type YieldRiskStakingRewardsDtoReportUrl = { [key: string]: unknown }; |
There was a problem hiding this comment.
Use a URL scalar type for reportUrl
Line 4 currently allows any object, which breaks type safety for a documented URL field and can hide invalid payload mappings in consumers.
Proposed fix
-export type YieldRiskStakingRewardsDtoReportUrl = { [key: string]: unknown };
+export type YieldRiskStakingRewardsDtoReportUrl = string;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export type YieldRiskStakingRewardsDtoReportUrl = { [key: string]: unknown }; | |
| export type YieldRiskStakingRewardsDtoReportUrl = string; |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/api/schemas/yieldRiskStakingRewardsDtoReportUrl.ts` at line 4, The
current broad index signature in the exported type
YieldRiskStakingRewardsDtoReportUrl should be replaced with an explicit URL
scalar property to enforce type safety: change the type to require a reportUrl
field (e.g., reportUrl: string or your project’s URL scalar type) instead of {
[key: string]: unknown }, update any serializers/validators that consume
YieldRiskStakingRewardsDtoReportUrl to validate/parse the URL value, and ensure
all usages of YieldRiskStakingRewardsDtoReportUrl (constructors, mappers, tests)
are updated to pass a reportUrl property.
| /** | ||
| * Staking Rewards score (1-5) | ||
| */ | ||
| export type YieldRiskStakingRewardsDtoScore = { [key: string]: unknown }; |
There was a problem hiding this comment.
Model score as a bounded numeric type (1–5)
Given Line 2’s explicit range, Line 4 should not be an open object; this currently loses critical validation at compile time.
Proposed fix
-export type YieldRiskStakingRewardsDtoScore = { [key: string]: unknown };
+export type YieldRiskStakingRewardsDtoScore = 1 | 2 | 3 | 4 | 5;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export type YieldRiskStakingRewardsDtoScore = { [key: string]: unknown }; | |
| export type YieldRiskStakingRewardsDtoScore = 1 | 2 | 3 | 4 | 5; |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/api/schemas/yieldRiskStakingRewardsDtoScore.ts` at line 4, Replace the
open-object type for YieldRiskStakingRewardsDtoScore with a bounded numeric type
so it only allows the integers 1 through 5; locate the type alias
YieldRiskStakingRewardsDtoScore and change its definition from a generic {[key:
string]: unknown} to a union of the allowed integer literals (1,2,3,4,5) or an
equivalent branded/validated numeric type so compile-time typing enforces the
1–5 range.
| /** | ||
| * Staking Rewards product type | ||
| */ | ||
| export type YieldRiskStakingRewardsDtoType = { [key: string]: unknown }; |
There was a problem hiding this comment.
type should be a scalar discriminator, not an object
Line 4 weakens the DTO by allowing arbitrary object shapes for a product type field.
Proposed fix
-export type YieldRiskStakingRewardsDtoType = { [key: string]: unknown };
+export type YieldRiskStakingRewardsDtoType = string;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export type YieldRiskStakingRewardsDtoType = { [key: string]: unknown }; | |
| export type YieldRiskStakingRewardsDtoType = string; |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/api/schemas/yieldRiskStakingRewardsDtoType.ts` at line 4, The DTO
currently declares YieldRiskStakingRewardsDtoType as a loose object ({ [key:
string]: unknown }) which allows arbitrary shapes; change it to a scalar
discriminator (e.g., a plain string or a string literal union/enum) so the
product type is a single scalar value. Update the declaration of
YieldRiskStakingRewardsDtoType to a scalar type (or a string enum of allowed
product types), and adjust any validation/serialization code and places that
import/use YieldRiskStakingRewardsDtoType to expect a scalar product type
instead of an object.
| /** | ||
| * Staking Rewards methodology version | ||
| */ | ||
| export type YieldRiskStakingRewardsDtoVersion = { [key: string]: unknown }; |
There was a problem hiding this comment.
Narrow version to a scalar version token
Line 4 exposes an object shape where a methodology version value is expected, reducing DTO correctness.
Proposed fix
-export type YieldRiskStakingRewardsDtoVersion = { [key: string]: unknown };
+export type YieldRiskStakingRewardsDtoVersion = string;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export type YieldRiskStakingRewardsDtoVersion = { [key: string]: unknown }; | |
| export type YieldRiskStakingRewardsDtoVersion = string; |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/api/schemas/yieldRiskStakingRewardsDtoVersion.ts` at line 4, The exported
type YieldRiskStakingRewardsDtoVersion is currently a catch-all object ({ [key:
string]: unknown }) but should be a scalar version token; change the type
definition of YieldRiskStakingRewardsDtoVersion from an open object to an
appropriate scalar (e.g., string or a narrow union of allowed tokens) and update
any validators or usages that expect a version token to reflect the new scalar
type so DTO correctness is restored.
1 participant
Summary by CodeRabbit
Release Notes
New Features
Chores