Release 0.10.12 #10
Release 0.10.12 #10
Conversation
…-version chore: update @super-protocol/sp-files-addon to version 0.9.4
* feat(offers): add support for value offer versioning (SP-5780) * build(deps): use @super-protocol/sdk-js (SP-5780) * feat(offersGetInfoCommand): remove "version" param from command (SP-5789) - because we don't have to make filter in graphql query yet (it will be added later) * fix(addValueOfferVersionService): handle contract error and invalid version param (SP-5780) * chore(deps): update @super-protocol/sdk-js to 3.4.0-beta.7 (SP-5780) --------- Co-authored-by: Dmitry Somov <smv.dmitry@gmail.com>
Merge main into staging
Merge staging into develop
Merge branch main into staging
Merge branch staging into develop
Update package.json
…on-file-upload chore: improve output path validation for files upload
* feat: move to opBNB tokens and names * fix: spaUrl and default backend url
Merge branch main into staging
Merge branch staging into develop
WalkthroughThis pull request implements extensive updates across configuration, dependency management, command logic, and service functions. Major changes include modifying RPC endpoints and backend URLs, updating package versions and dependencies, and transitioning token handling from MATIC to BNB. The pull request also introduces comprehensive offer versioning support by enforcing stricter type requirements and renaming version-related properties to "offerVersion" across multiple modules. Additionally, GraphQL schema definitions have been enhanced, new helper functions for version management added, and minor typo corrections applied. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant OfferService
participant BlockchainConnector
participant VersionHelper
Client->>OfferService: createValueOffer(params)
Note over OfferService: Validate offer info and determine version
OfferService->>VersionHelper: selectLastValueOfferVersion(versions)
VersionHelper-->>OfferService: Latest version (if any)
OfferService->>OfferService: Call addValueOfferVersion (with new version info)
OfferService->>BlockchainConnector: setNewVersion(offerId, versionInfo)
alt Offer is not enabled
OfferService->>BlockchainConnector: enable(offer)
end
OfferService-->>Client: Return created offer with version
sequenceDiagram
participant CLI
participant TokenService
participant BlockchainConnector
CLI->>TokenService: Initiate tokensCommand (--bnb flag)
TokenService->>BlockchainConnector: getBnbBalance(address)
BlockchainConnector-->>TokenService: Return BNB balance
TokenService-->>CLI: Display BNB token balance and status
Poem
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🔭 Outside diff range comments (2)
src/index.ts (2)
781-785:⚠️ Potential issueInconsistent analytics event naming
While the conditional check has been updated to
options.bnb, the analytics event name is stillAnalyticEvent.MATIC_TOKENS_REPLENISHED, which creates an inconsistency between the token being requested and the event being tracked.Update the analytics event name to reflect the BNB token:
- eventName: AnalyticEvent.MATIC_TOKENS_REPLENISHED, + eventName: AnalyticEvent.BNB_TOKENS_REPLENISHED,Verify that this constant is defined in the analytics service.
795-802:⚠️ Potential issueInconsistent analytics error event naming
Similarly to the success event, the error tracking event name needs to be updated to reflect the transition from MATIC to BNB tokens.
Update the analytics error event name:
- eventName: AnalyticEvent.MATIC_TOKENS_REPLENISHED, + eventName: AnalyticEvent.BNB_TOKENS_REPLENISHED,
🧹 Nitpick comments (6)
src/services/offerValueVersionHelper.ts (1)
3-17: Improve the return type clarity and edge case handling.The function correctly selects the last offer version with "New" status, but I see a few areas for improvement:
- The conditional return could be more explicit about returning
undefinedfor empty arrays or when no "New" status versions are found.- The function lacks a return type annotation, which would improve code readability.
export const selectLastValueOfferVersion = ( versions?: OfferVersion[], -): OfferVersion | undefined => { +): OfferVersion | undefined => { + if (!versions?.length) { + return undefined; + } + const version = versions ?.filter((v) => v.status === OfferVersionStatus.New) .reduce((max, current) => (current.version > max.version ? current : max), { version: Number.MIN_SAFE_INTEGER, info: {}, status: OfferVersionStatus.New, }); if (version?.version !== Number.MIN_SAFE_INTEGER) { return version; } + return undefined; };src/services/getBnbBalance.ts (2)
8-8: Renamed function from getMaticBalance to getBnbBalance.The function has been renamed to reflect the token change from MATIC to BNB. However, the function is missing a return type annotation.
-const getBnbBalance = async (params: GetMumbaiBalanceParams) => { +const getBnbBalance = async (params: GetMumbaiBalanceParams): Promise<BigNumber> => {🧰 Tools
🪛 ESLint
[error] 8-8: Missing return type on function.
(@typescript-eslint/explicit-function-return-type)
4-6: Consider updating parameter type name for consistency.The function has been renamed from
getMaticBalancetogetBnbBalance, but the parameter typeGetMumbaiBalanceParamsstill references Mumbai (Polygon testnet). For consistency, you might want to rename this type as well.-export type GetMumbaiBalanceParams = { +export type GetBnbBalanceParams = { address: string; };src/services/createValueOffer.ts (1)
65-70: Consider dynamic version assignment.Hardcoding the version to 1 might be restrictive if version 1 already exists. Consider fetching the latest version and incrementing it automatically.
src/services/workflowHelpers.ts (1)
104-110: Populating version with selectLastValueOfferVersion.Casting the fetched list to
FetchedOffer[]is convenient but consider validating item shapes or handling potential mismatches. Overall logic is sound for returning version data.src/gql/index.ts (1)
8653-8693: Consider using a GraphQL enum forstatus.Here,
statusis set as a string but the JSDoc suggests discrete values ("0","1"). A GraphQL enum would enforce stricter typing and clarity. Also, confirm whetherversionshould be an integer instead of float.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (35)
config.example.json(1 hunks)package.json(2 hunks)src/commands/filesUpload.addon.ts(1 hunks)src/commands/offersCreate.ts(3 hunks)src/commands/offersGetInfo.ts(2 hunks)src/commands/offersUpdateSlot.ts(1 hunks)src/commands/ordersCreate.ts(5 hunks)src/commands/secrets/storage/command-builders.ts(3 hunks)src/commands/secrets/storage/register/action.ts(4 hunks)src/commands/secrets/storage/register/command.ts(1 hunks)src/commands/secrets/storage/service.ts(5 hunks)src/commands/secrets/storage/status/action.ts(2 hunks)src/commands/secrets/storage/status/command.ts(1 hunks)src/commands/secrets/storage/status/service.ts(1 hunks)src/commands/secrets/storage/update/action.ts(3 hunks)src/commands/secrets/utils.ts(6 hunks)src/commands/tokensBalance.ts(2 hunks)src/commands/tokensRequest.ts(2 hunks)src/commands/workflowsCreate.ts(3 hunks)src/config.ts(2 hunks)src/constants.ts(1 hunks)src/gql/index.ts(11 hunks)src/gql/schemas/offers.graphql(1 hunks)src/index.ts(4 hunks)src/services/addValueOfferVersion.ts(1 hunks)src/services/calcWorkflowDeposit.ts(2 hunks)src/services/createValueOffer.ts(3 hunks)src/services/createWorkflow.ts(0 hunks)src/services/getBnbBalance.ts(1 hunks)src/services/offerValueVersionHelper.ts(1 hunks)src/services/readValueOfferInfo.ts(2 hunks)src/services/readValueOfferSlot.ts(1 hunks)src/services/requestBnb.ts(1 hunks)src/services/requestCustomBnb.ts(1 hunks)src/services/workflowHelpers.ts(4 hunks)
💤 Files with no reviewable changes (1)
- src/services/createWorkflow.ts
🧰 Additional context used
🧬 Code Definitions (16)
src/commands/offersCreate.ts (4)
src/services/readValueOfferInfo.ts (1)
readValueOfferInfo(66-100)src/services/createValueOffer.ts (1)
params(25-81)src/services/createTeeOffer.ts (1)
params(15-58)src/services/addValueOfferVersion.ts (1)
params(18-52)
src/commands/tokensBalance.ts (1)
src/utils.ts (1)
weiToEther(130-138)
src/commands/secrets/storage/status/action.ts (1)
src/commands/secrets/utils.ts (1)
findLastOfferVersion(91-101)
src/config.ts (1)
src/constants.ts (1)
BACKEND_URL_DEFAULT(10-10)
src/services/offerValueVersionHelper.ts (1)
src/gql/index.ts (1)
OfferVersion(8653-8666)
src/commands/secrets/storage/command-builders.ts (1)
src/commands/secrets/constants.ts (4)
SPCTL_COMMAND(1-1)SECRETS_COMMAND(2-2)STORAGE_COMMAND(3-3)STATUS_COMMAND(6-6)
src/commands/filesUpload.addon.ts (1)
src/commands/filesUpload.ts (1)
params(21-182)
src/commands/workflowsCreate.ts (1)
src/services/workflowHelpers.ts (1)
FetchedOffer(21-26)
src/services/calcWorkflowDeposit.ts (1)
src/services/workflowHelpers.ts (1)
FetchedOffer(21-26)
src/commands/secrets/storage/update/action.ts (3)
src/commands/secrets/utils.ts (1)
findLastOfferVersion(91-101)src/commands/secrets/storage/status/command.ts (1)
statusCommand(5-9)src/commands/secrets/storage/command-builders.ts (1)
buildStatusCommand(54-69)
src/services/addValueOfferVersion.ts (3)
src/gql/index.ts (3)
OfferVersionInfo(8668-8673)Offer(8407-8424)OfferVersion(8653-8666)src/services/createValueOffer.ts (1)
params(25-81)src/commands/offersCreate.ts (1)
params(30-107)
src/commands/offersGetInfo.ts (2)
src/gql/index.ts (3)
OfferInfo(8491-8526)OfferVersion(8653-8666)TeeOfferInfo(9773-9782)src/services/offerValueVersionHelper.ts (1)
selectLastValueOfferVersion(3-17)
src/commands/secrets/storage/register/action.ts (3)
src/commands/secrets/storage/service.ts (1)
RegisterStorageParams(21-28)src/commands/secrets/utils.ts (1)
findLastOfferVersion(91-101)src/commands/secrets/storage/command-builders.ts (1)
buildStatusCommand(54-69)
src/services/createValueOffer.ts (2)
src/gql/index.ts (3)
OfferInfo(8491-8526)OfferVersionInfo(8668-8673)Offer(8407-8424)src/services/addValueOfferVersion.ts (1)
params(18-52)
src/commands/ordersCreate.ts (1)
src/services/workflowHelpers.ts (2)
FetchedOffer(21-26)getFetchedOffers(96-112)
src/services/workflowHelpers.ts (2)
src/gql/index.ts (1)
OfferVersion(8653-8666)src/services/offerValueVersionHelper.ts (1)
selectLastValueOfferVersion(3-17)
🪛 ESLint
src/services/getBnbBalance.ts
[error] 8-8: Missing return type on function.
(@typescript-eslint/explicit-function-return-type)
🔇 Additional comments (100)
config.example.json (1)
7-7: Updated blockchain RPC URL from Polygon to opBNBThe configuration has been updated to use opBNB network instead of Polygon. This change is part of the transition from MATIC to BNB tokens mentioned in the PR summary.
Please verify that the smart contract address (line 8) is still valid for the opBNB network, as it remained unchanged during this transition.
src/services/readValueOfferSlot.ts (1)
15-15: Added metadata support to ValueOfferSlotFileValidatorThe addition of the metadata field with a default empty string value provides backward compatibility while enabling the new offer versioning functionality mentioned in the PR summary.
src/services/requestCustomBnb.ts (1)
25-25: Updated error message to reflect BNB token usageThe error message has been changed from 'MATIC tokens request error' to 'BNB tokens request error', aligning with the broader transition from MATIC to BNB tokens across the codebase.
src/services/requestBnb.ts (1)
25-25: Updated error message to reflect BNB token usageThe error message has been changed from 'MATIC tokens request error' to 'BNB tokens request error', aligning with the broader transition from MATIC to BNB tokens across the codebase.
src/commands/secrets/storage/register/command.ts (1)
8-8: Command option renamed for clarityThe option
--version <number>has been renamed to--offer-version <number>to clearly indicate that this version relates to the solution offer. This change improves clarity and is consistent with the standardization of naming conventions for versioning across the codebase.src/commands/secrets/storage/status/command.ts (1)
8-8: Command option renamed for consistencyThe option
--version <number>has been renamed to--offer-version <number>to maintain consistency with other commands in the codebase. This is part of the broader effort to standardize versioning terminology across the application.src/commands/tokensBalance.ts (2)
2-2: Service import updated from MATIC to BNBThe import has been updated from
getMaticBalanceServicetogetBnbBalanceServiceas part of the transition from MATIC to BNB tokens throughout the application.
29-31: Token reference updated from MATIC/POL to BNBThe code has been updated to fetch and display BNB token balances instead of MATIC/POL tokens. Variable names and output messages have been modified accordingly to reference BNB.
src/commands/offersUpdateSlot.ts (1)
47-47:Details
❓ Verification inconclusive
Added metadata parameter to updateSlot method
The
metadataparameter has been added to theupdateSlotmethod call for value offers, extending the functionality to include metadata in the update process. This enhancement aligns with the broader improvements in offer versioning support.Ensure that the
Offer.updateSlotmethod signature in the SDK has been updated to accept this additional parameter, and thatvalueOfferSlot.metadatais properly initialized in thereadValueOfferSlotfunction.
🏁 Script executed:
#!/bin/bash # Check if the updateSlot method in the SDK expects this new parameter rg -A 2 "updateSlot.*metadata" --type typescriptLength of output: 85
Below is a revised review comment. I’ve also generated a new shell script using the correct file type (using
--type tsinstead of--type typescript) to verify that the SDK’sOffer.updateSlotmethod signature includes the newmetadataparameter. Please run this script and check its output to confirm that the SDK has been updated accordingly.
Verify SDK Update for Metadata Parameter
The commit now includes the
metadataparameter in theupdateSlotcall for value offers, which extends support for offer versioning improvements. Please verify the following:
- The SDK’s
Offer.updateSlotsignature accepts the newmetadataparameter.- The
valueOfferSlot.metadatais properly initialized in thereadValueOfferSlotfunction.Below is the updated shell script for verification:
If the script output confirms the updated method signature, you can consider this change approved. If not, please investigate further.
🏁 Script executed:
#!/bin/bash # Re-run the verification for the SDK's updateSlot method using the recognized file type for TypeScript files. rg -A 2 "updateSlot.*metadata" --type tsLength of output: 164
Verify SDK Update for Metadata Parameter
The commit now includes the
metadataparameter in theupdateSlotcall for value offers, extending support for enhanced offer versioning. However, our automated search using the correct file type yielded no output. Please manually verify that:
- The
Offer.updateSlotmethod signature in the SDK has been updated to accept themetadataparameter.- The
valueOfferSlot.metadatais properly initialized in thereadValueOfferSlotfunction.src/services/calcWorkflowDeposit.ts (2)
10-10: Typo correction - fixing imported type name.The import has been corrected from
FethchedOffertoFetchedOffer, fixing a typo in the type name.
21-21: Typo correction - fixing type reference.The type reference has been corrected from
FethchedOffertoFetchedOffer, maintaining consistency with the type defined in theworkflowHelpers.tsfile.src/commands/secrets/storage/status/service.ts (1)
15-15: Made offerVersion a required parameter.The
offerVersionparameter is now required rather than optional, which strengthens the type safety and aligns with how it's being used in the function implementation. This change is consistent with the broader pattern in the codebase to standardize version handling.src/services/getBnbBalance.ts (1)
13-13: Updated export to use the new function name.The export statement correctly reflects the renamed function.
src/commands/offersCreate.ts (3)
27-27: Good addition of optional enabled flag.Adding this optional property enhances flexibility by allowing clients to create offers in a disabled state if needed.
60-60: Improved destructuring of version information.Extracting the version data from the offer info properly separates concerns and allows for better version management.
97-98: Enhanced offer creation with version info and enablement control.The changes correctly pass version information to the offer creation process and provide a sensible default for the
enabledflag (true if not specified).src/config.ts (2)
5-5: Added import for backend URL constant.The import of
BACKEND_URL_DEFAULTfrom the constants file is necessary for the new mainnet URL handling.
197-200: Added specific handling for mainnet URLs.The changes improve URL resolution by adding explicit handling for the mainnet environment, returning the appropriate SPA URL when the backend URL matches the default (mainnet) URL.
src/commands/secrets/storage/status/action.ts (3)
5-5: Added import for version utility function.This import supports the enhancement to find the last offer version when none is explicitly provided.
8-8: Standardized naming convention for offer version.Renaming from
versiontoofferVersionimproves consistency with the rest of the codebase and makes the API more intuitive.
28-30: Enhanced version handling with fallback mechanism.This improvement adds automatic retrieval of the latest offer version when none is specified, making the API more user-friendly while maintaining backward compatibility.
src/commands/filesUpload.addon.ts (1)
179-188: Added safeguard against overwriting existing files.This change adds an important validation check to prevent accidentally overwriting existing files. The error handling properly distinguishes between the expected "file not found" case and other potential errors.
package.json (2)
3-3: Package version bump looks good.The version has been updated from 0.10.11 to 0.10.12, which aligns with the PR title "Release 0.10.12".
39-40:Details
✅ Verification successful
Dependency updates are appropriate.
The SDK dependency is updated to a newer beta version with more flexible versioning (
^3.5.0-beta.2), and the files addon is updated to a newer patch version (^0.9.6). These changes support the new offer versioning functionality introduced in this PR.
🏁 Script executed:
#!/bin/bash # Verify that the updated SDK dependencies are compatible with the current code # Check imports from @super-protocol/sdk-js echo "Checking for imports of new SDK classes (particularly versioning related):" rg -A 1 "import.*@super-protocol/sdk-js" --glob "*.ts" # Check for usages of any version-related functionality echo "Checking for usages of versioning functionality:" rg "offerVersion|OfferVersion" --glob "*.ts"Length of output: 22329
SDK Dependency and Files Addon Updates Verified
The dependency updates in
package.json(lines 39-40) have been confirmed as appropriate. The updated SDK dependency (@super-protocol/sdk-jsat^3.5.0-beta.2) and the files addon (@super-protocol/sp-files-addonat^0.9.6) are correctly integrated across the codebase. The verification script confirms that versioning functionality (e.g., usage ofofferVersion) is present and properly utilized in numerous modules. No additional changes are required.src/gql/schemas/offers.graphql (1)
73-81: New versions field properly structures the offer versioning support.The addition of the
versionsfield to the query provides a well-structured way to handle multiple offer versions, each with its own metadata, hash, and signature information. This change supports the architectural shift mentioned in the PR description regarding offer versioning.The nested structure with
version,status, andinfofields provides a clear organization of version-specific data that was previously at the offer level.src/commands/workflowsCreate.ts (2)
43-43: Fixed type name typo.The type name has been corrected from
FethchedOffertoFetchedOffer, enhancing code consistency.
484-485:Details
✅ Verification successful
Updated property access paths to match new versioning structure.
The property paths have been updated to access version-specific fields through the new
versionproperty, which aligns with the architectural changes for offer versioning.
🏁 Script executed:
#!/bin/bash # Verify that null/undefined handling is appropriate for these optional fields # Check if there are any null checks for version before accessing its properties echo "Checking for null checks on version property:" rg "version\s*(\?\.|&&|\?)" src/commands/ # Check how optional chaining is used with version properties echo "Checking usage of optional chaining with version properties:" rg "version\?\.info" src/Length of output: 1040
Final Approval: Updated Property Access Paths Verified
The updated property access paths in
src/commands/workflowsCreate.tscorrectly use optional chaining to safely access new version-specific fields. The shell script output confirms that bothoffer.version?.info.hash?.hashand similar patterns (e.g.,offer.version?.info.signatureKeyHash?.hash) are properly guarded via optional chaining. This aligns with the architectural changes for offer versioning and ensures appropriate null/undefined handling.
- Verified Location:
src/commands/workflowsCreate.ts(Lines 484-485)- Consistency Check: Similar usage in
src/commands/offersGetInfo.tsconfirms uniform handling across related files.No further modifications are necessary.
src/commands/secrets/storage/command-builders.ts (4)
22-22: Updated version parameter name for clarity.The property name has been changed from
versiontoofferVersionin the register command, which improves clarity by explicitly tying it to the offer context.
43-43: Updated version parameter name for consistency.The property name has been updated from
versiontoofferVersionin the update command, maintaining consistent naming across the codebase.
56-56: Made offerVersion parameter required and renamed for clarity.The type definition has been updated to make
offerVersiona required property (instead of an optionalversion), which enforces proper usage of the status command.
64-64:Details
❓ Verification inconclusive
Updated command-line flag for consistency.
The command-line flag has been changed from
--versionto--offer-version, which aligns with the naming convention used throughout the codebase and clarifies its purpose.
🏁 Script executed:
#!/bin/bash # Verify that the command-line flag change is consistent across the codebase # Check for any remaining --version flags in commands related to offers echo "Checking for any remaining --version flags that should be updated:" rg " --version " --glob "*.ts" src/commands/ # Check for usage of --offer-version flag to ensure consistency echo "Checking usage of --offer-version flag:" rg " --offer-version " --glob "*.ts" src/commands/Length of output: 331
Consistency Check for Updated Command-line Flag
- The flag has been updated from
--versionto--offer-versionto align with the naming convention.- A search for residual
--versionoccurrences in the commands did not return any results.- The change appears consistent; however, the absence of output from the search warrants manual verification to ensure the update is fully propagated.
src/commands/secrets/storage/update/action.ts (3)
7-7: Improved modularity through utility function importThe addition of the
findLastOfferVersionutility function enhances the code's modularity by centralizing version retrieval logic, which can be reused across multiple commands.
37-39: Good enhancement to version handlingThe implementation of conditional version assignment is a positive improvement that:
- Uses the explicitly provided version when available
- Falls back to retrieving the latest version automatically when not specified
This makes the function more flexible and user-friendly.
67-70: Improved parameter passing specificityThis change improves the code by explicitly passing only the required parameters (
offerVersionandconfig) to thebuildStatusCommandfunction instead of passing the entireoptionsobject. This makes the dependencies clearer and aligns with the updated signature ofbuildStatusCommandshown in the relevant code snippets.src/commands/tokensRequest.ts (4)
3-5: Transitioning from MATIC to BNB token servicesThe imports have been updated to reflect the transition from MATIC to BNB token handling services, which is consistent with the changes throughout the file. This suggests a platform migration from Polygon to BNB Chain.
13-13: Updated token request parameter typeThe
TokensRequestParamstype has been updated to replacerequestMaticwithrequestBnb, reflecting the transition to BNB tokens in the system.
19-22: Updated token type checking and user guidanceThe conditional check and help message have been modified to reflect the new token type (BNB instead of MATIC), maintaining consistent user guidance throughout the interface.
44-52: Token service integration updated for BNBThe token request implementation has been updated to work with BNB instead of MATIC tokens, including:
- Updated console messaging to inform users about opBNB tokens
- Service calls changed to use BNB-specific services
- Success confirmation messages updated for consistency
This completes the token handling transition in this module.
src/index.ts (2)
752-752: Updated token request CLI optionThe CLI option has been updated from
--maticto--bnbwith an appropriate description change to reflect the platform transition from Polygon to opBNB.
769-769: Updated token request parameter nameThe parameter name in the request object has been changed from
requestMatictorequestBnbto maintain consistency with the type definition changes insrc/commands/tokensRequest.ts.src/commands/ordersCreate.ts (5)
21-21: Fixed type name typoThe type name has been corrected from
FethchedOffertoFetchedOffer, improving code consistency and preventing potential confusion.
71-72: Updated return type and variable declarationThe function's return type and variable declaration have been updated to use the corrected type name
FetchedOffer, ensuring type consistency.
83-83: Consistent type usage for offer variableVariable type annotation updated to use the corrected
FetchedOffertype, maintaining consistency throughout the file.
101-101: Updated Map type parameterThe Map type parameter in the
checkFetchedOffersfunction call has been updated to use the correctedFetchedOffertype, ensuring proper type checking.
244-244: Consistent type usage in function callThe variable type annotation in the function call has been updated to use the corrected
FetchedOffertype, completing the typo correction throughout the file.src/constants.ts (1)
10-12:Details
✅ Verification successful
Significant URL and address changes detected
The changes involve migrating from test environment to production, moving from Polygon testnet to BNB Chain:
- Backend URL changed from testnet to production
- Blockchain RPC URL changed from Polygon Amoy testnet to opBNB
- Smart contract address updated to match the new blockchain
This represents a major environment shift. Ensure all dependent systems are aware of these changes and update their configurations accordingly.
🏁 Script executed:
#!/bin/bash # Check if these constants are referenced elsewhere in the codebase echo "Checking for references to these constants:" rg -A 2 -B 2 "BACKEND_URL_DEFAULT|BLOCKCHAIN_RPC_URL_DEFAULT|SMART_CONTRACT_ADDRESS_DEFAULT" --type ts echo "Checking if config.example.json has been updated with the new URLs:" find . -name "config.example.json" -type f -exec cat {} \; | grep -E "opbnb.superprotocol.com|0x3C69ea105Fc716C1Dcb41859281Aa817D0A0B279"Length of output: 3055
Environment Transition Update Verified
The updated defaults in
src/constants.tshave been correctly changed to point to the production backend and blockchain configuration (BNB Chain via opBNB). Our verification confirms that:
- References in
src/config.tsandsrc/commands/setup.tsare correctly using the updated constants.- The
config.example.jsonfile has been updated to include the new URLs and smart contract address.Please ensure that any external systems or environments relying on these settings are notified accordingly.
src/commands/offersGetInfo.ts (4)
1-7: Added support for offer versioningNew imports enhance the offers module with versioning capabilities, enabling better version management.
18-18: Type enhancement for offer variableThe type definition has been improved to accommodate versioning by allowing an optional version property on OfferInfo objects.
20-28: Code style improvement with bracesAdded braces to the 'tee' case for consistent code style and to prevent potential bugs if more code is added in the future.
29-49: New utility function to handle offer versionsThe added
convertfunction enhances the code by:
- Extracting version information from offer data
- Selecting the latest version with appropriate status
- Combining this with offer info to create a comprehensive response
This implementation correctly handles undefined offers and intelligently merges version data when available.
src/services/addValueOfferVersion.ts (4)
1-16: Well-structured type definition and importsThe imports and type definition for
AddOfferVersionParamsare clearly organized, with appropriate types from the SDK and necessary parameters for the function.
18-24: Proper validation of input parametersThe function correctly initializes the blockchain connector and validates the version number, ensuring it's non-negative. This prevents invalid version numbers from being processed.
28-43: Improved error handling for version collisionsThe implementation properly:
- Retrieves the current version count
- Handles the case where a specific version is requested
- Catches
NotFoundErrorappropriately when checking if a version exists- Throws a clear error message when trying to create a version that already exists
This prevents duplicate versions and provides clear feedback to users.
44-52: Clean version assignment and operationThe function:
- Assigns a version number based on user input or auto-increments
- Sets the new version with proper parameters
- Provides informative output to the user
- Returns the new version number for use by calling functions
This implementation is concise and functional.
src/commands/secrets/storage/register/action.ts (6)
7-7: Added utility import for version managementThe import of
findLastOfferVersionenhances the module's capability to retrieve the latest version when a specific version isn't provided.
10-10: Property renamed from 'version' to 'offerVersion'This change improves naming consistency across the codebase by aligning with other occurrences of "offerVersion".
40-40: Updated parameter name for consistencyThe parameter passed to
checkParamsToRegisterStoragenow usesofferVersionfor better clarity and consistency.
47-49: Enhanced version handling with fallback mechanismThe code now intelligently:
- Uses the explicitly provided version when available
- Automatically retrieves the latest version as fallback
- Ensures that a valid version is always assigned
This makes the API more robust and user-friendly while maintaining version consistency.
77-80: Updated status command building with version informationThe status command builder now receives the correct version parameter, ensuring that status commands generated will reference the correct offer version.
94-94: Strengthened type safety for findStorageOrderId functionThe parameter type has been enhanced from
Pick<OfferStorageRequest, 'offerId' | 'offerVersion'>toPick<Required<OfferStorageRequest>, 'offerId' | 'offerVersion'>, ensuring that both properties are required and preventing potential null/undefined errors.src/services/createValueOffer.ts (5)
1-8: Imports look consistent and necessary.No concerns about these imported modules. They align well with the usage in this module.
13-13: New import for addValueOfferVersion.This inclusion appears appropriate. Ensure error handling for addValueOfferVersion exceptions is handled upstream or in the caller if needed.
45-49: Refined arguments for Offers.create.Calling
Offers.createwith clearer named parameters is more expressive and maintains readability. Looks good.
72-78: Conditional enabling of the offer.This logic is straightforward and ensures that the offer is only enabled when required. The approach is sound.
22-22:Details
❓ Verification inconclusive
Check usage of the new enabled property.
You added a new property
enabled. Confirm that every caller ofcreateValueOffersets this correctly or has a default, to avoid unexpected behavior.
🏁 Script executed:
#!/bin/bash rg -A 3 'createValueOffer\('Length of output: 336
Let's see if the function signature or body sets a default value for the new
enabledproperty.
🏁 Script executed:
#!/bin/bash rg -A 10 "function createValueOffer" src/services/createValueOffer.tsLength of output: 71
Action: Verify “enabled” Property Handling in createValueOffer
It appears that the only observed call (in
src/commands/offersCreate.ts) does not pass an explicit value for the newenabledproperty. Please ensure one of the following:
- The implementation in
src/services/createValueOffer.tsprovides a default value forenabledwhen it’s not supplied.- Alternatively, update all call sites (currently,
src/commands/offersCreate.ts) to explicitly setenabledas required.This verification is necessary to avoid any unintended behavior due to an undefined or unexpected value for
enabled.src/commands/secrets/storage/service.ts (5)
32-32: Optional parameter in internal check function.
offerVersionremains optional here for fallback logic, which can be acceptable. Ensure this partial signature does not cause confusion whenofferVersionis mandatory at higher levels.
41-52: Robust validation for offer versions.Good checks for undefined, non-existent, or invalid version numbers. This prevents registering storage against invalid or non-existing versions.
72-72: Passing offerVersion to setOfferStorageRequest.This ensures consistency with the newly enforced version usage. No issues found.
137-137: Replication factor properly set.Assigning
replicationFactorhere is correct. Just confirm that the upstream logic ensures valid replicationFactor values.
23-23:Details
✅ Verification successful
Confirm backward compatibility for mandatory offerVersion.
Previously,
offerVersionmight have been optional. Now it is mandatory inRegisterStorageParams. Verify that no existing calls are missing this property.
🏁 Script executed:
#!/bin/bash rg -A 3 'RegisterStorageParams'Length of output: 2264
Backward Compatibility Confirmed: Mandatory
offerVersionis consistently providedThe grep output confirms that all instances creating a
RegisterStorageParamsobject include theofferVersionproperty. In both the registration and update actions (as seen insrc/commands/secrets/storage/register/action.tsandsrc/commands/secrets/storage/update/action.ts), the property is explicitly provided. There are no calls missing this field.src/services/workflowHelpers.ts (6)
2-2: Expanded imports with OfferVersion.The additional import for
OfferVersionis appropriate, matching the usage in this code.
16-16: Importing selectLastValueOfferVersion.This is coherent with the approach of attaching the latest version data to offers.
21-25: Type FetchedOffer gains version property.Adding
version?: OfferVersion;provides a structured way to store offer version details. This maintains flexibility if some offers lack version info.
29-29: Map<string, FetchedOffer> type usage.Changing the collection type to store
FetchedOfferobjects improves clarity.
70-70: Ensuring correct type for offers parameter.Using
Map<string, FetchedOffer>is consistent, confirming that each entry is the new typed structure.
101-101: Function returns array of FetchedOffer.Refactoring the return type to
Promise<FetchedOffer[]>matches the updated internal representation.src/services/readValueOfferInfo.ts (8)
2-7: Updated imports to include OfferVersion typeThe import statement now includes
OfferVersionfrom the SDK, which will be used for the newly introduced versioning support in this file.
18-22: Schema naming standardizationThe validator has been appropriately renamed from
OfferInfoRestrictionsValidatortoOfferInfoRestrictionsSchemato maintain consistency with other schema definitions in the file.
24-32: New version schema definitionThe newly introduced schema definitions properly structure offer versioning information, with appropriate fields for metadata, hashes, and version numbers.
33-48: Updated OfferInfoSchema with version supportThe OfferInfoSchema has been extended to include version information while making the version number optional, which allows backward compatibility with existing offer information.
50-55: Validator restructuringThe validators have been restructured to accommodate the new versioning system. The optional validator now properly omits the version field and extends with a partial restrictions schema.
57-58: Type definitions for versioned offer infoNew type definitions have been added to properly represent offer information with versioning support.
60-69: Updated function signatures with new return typesThe function signatures have been updated to return the new types, providing better type safety and representing the new structure of the offer information.
72-72: Updated validator usageThe validator used in the readJsonFile call has been updated to use the new schema definitions, maintaining consistency with the type changes.
src/commands/secrets/utils.ts (6)
8-13: Updated imports for more specific access controlThe imports have been updated to use more specific types (
LoaderSecretAccessPublicKeyandLoaderSecretsAccessPublicKeys) and added theOfferclass which is needed for the newfindLastOfferVersionfunction.
22-22: Updated type for secret parameterThe type for the secret parameter has been updated to use the more specific
LoaderSecretAccessPublicKeytype.
49-49: Updated method call for accessing secretsThe method call has been updated to use
LoaderSecretsAccessPublicKeys.get()instead of the previous implementation, aligning with the type changes introduced.
80-80:Details
✅ Verification successful
Updated function parameter type to enforce required fields
Similar to the previous function, the parameter type for
findRequestOrderIdnow usesRequired<OfferStorageRequest>to enforce that bothofferIdandofferVersionmust be provided.Check that all calls to this function provide both parameters.
🏁 Script executed:
#!/bin/bash # Search for calls to findRequestOrderId to ensure both parameters are provided rg "findRequestOrderId\(" -A 5 -B 5Length of output: 536
Parameter enforcement verified: All calls supply required fields.
The update to the function parameter type in
src/commands/secrets/utils.tsnow mandates that bothofferIdandofferVersionare provided. Our search results confirm that the sole call tofindRequestOrderIdinsrc/commands/secrets/storage/register/action.tspasses theparamsvariable—which is expected to contain both fields based on its enforced type. No additional calls were found that could potentially violate the new requirement.
61-61:Details
✅ Verification successful
Updated function parameter type to enforce required fields
The parameter type for
findAllocatedOrderIdnow usesRequired<OfferStorageRequest>to enforce that bothofferIdandofferVersionmust be provided.This change might break existing code if these properties were previously treated as optional. Verify that all calls to this function provide both parameters.
🏁 Script executed:
#!/bin/bash # Search for calls to findAllocatedOrderId to ensure both parameters are provided rg "findAllocatedOrderId\(" -A 5 -B 5Length of output: 1857
Verified: All call sites pass the required parameters
The updated parameter type now enforces that both
offerIdandofferVersionare present. A search across the codebase confirmed that all calls—specifically in:
- src/commands/secrets/storage/update/action.ts
- src/commands/secrets/storage/register/action.ts
…pass a
paramsobject that already includes both required fields.No breaking changes appear to be introduced by this update.
91-101:Details
✅ Verification successful
Added function to find the last offer version
A new utility function
findLastOfferVersionhas been added to retrieve the last version number for a given offer ID. The function properly handles the case when no version is found by throwing an appropriate error.Run the following script to see where this new function is being used in the codebase:
🏁 Script executed:
#!/bin/bash # Search for usages of the new findLastOfferVersion function rg "findLastOfferVersion\(" -A 3Length of output: 1068
Function Integration Confirmed: The new utility is correctly implemented and utilized.
The addition of the
findLastOfferVersionfunction insrc/commands/secrets/utils.ts(lines 91-101) is verified and working as expected. This function retrieves the last version number for an offer and appropriately throws an error when no version is found. Furthermore, the results from the usage search confirm that this function is consistently invoked in:
src/commands/secrets/storage/update/action.tssrc/commands/secrets/storage/register/action.tssrc/commands/secrets/storage/status/action.tsNo further changes are needed.
src/gql/index.ts (10)
8423-8423: Add tests for new optional field.This new
versions?: Maybe<Array<OfferVersion>>field allows for multiple offer versions. Consider adding tests to ensure this field is being populated and handled correctly in queries and mutations.
8483-8484: Document the new search field usage.The
search?: InputMaybe<Scalars['String']>filter is a great addition. Ensure it is documented and tested so that both backend and frontend teams understand how to filter by ID or name.
8573-8573: Keep consistency betweenOfferandOfferInput.Adding
versions?: InputMaybe<Array<OfferVersionInput>>maintains consistency with theOffertype. This looks good; be sure any downstream logic for handling versions is well-tested.
9191-9192:_idnaming consistency.The property
_id?: InputMaybe<Scalars['String']>is common in MongoDB-based schemas. This is fine, but confirm that other filters also use_idfor consistency. Otherwise, this looks good.
9268-9269: Validate resolver for newly introduced query.
getUsedPipelineTypesByEnginesis a useful addition. Ensure the corresponding resolver logic is in place and aligns with the pipeline retrieval process.Would you like a script to confirm the existence of the resolver implementation?
9350-9353: Match argument usage with resolvers.The new arguments for
QueryGetUsedPipelineTypesByEnginesArgsappear correct. Double-check that your resolvers and services handle thefilterandpipelineTypeSourcefields as intended.
9408-9408: Confirm backward compatibility for query arguments.Replacing
_idwithfilterinQueryProviderArgsmight affect existing calls. Verify that all references toQueryProviderArgsand its_idparameter have been updated accordingly.
9761-9762: Consistent search behavior.Adding
search?: InputMaybe<Scalars['String']>mirrors the pattern from the earlier filter addition. This ensures a uniform approach for searching TEE offers by ID or name.
10039-10039: Check usage of extended fields in queries.
OffersQuerynow retrievesversionsdata. Confirm that services and consumers can handle these newly introduced fields in the response without errors.
10269-10277: Ensure frontend integration forversionsfield.The
versionssubfield in the query results is now exposed. Make sure any consuming clients are updated to handle and display multiple offer versions properly.
| authority: string; | ||
| action: string; | ||
| offerInfo: OfferInfo; | ||
| versionInfo: OfferVersionInfo; |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Confirm all calls pass versionInfo.
The new required property versionInfo ensures versioning data is available. If there are other callers of createValueOffer, verify they also provide this parameter.
Run the following script to locate all createValueOffer calls and confirm they pass versionInfo:
🏁 Script executed:
#!/bin/bash
rg -A 3 'createValueOffer\('Length of output: 336
Action Required: Ensure all calls to createValueOffer include the new versionInfo parameter.
- In
src/commands/offersCreate.ts, the current call tocreateValueOfferonly passesauthority,action, andcontractAddress. It must be updated to pass aversionInfovalue as well. - Please verify that any other invocations of
createValueOffer(if present) also provide a validversionInfo.
Summary by CodeRabbit
New Features
Bug Fixes
Refactor