Skip to content

Conversation

QuantumExplorer
Copy link
Member

@QuantumExplorer QuantumExplorer commented May 26, 2025

Issue being fixed or feature implemented

Fixes the logic for calculating stepwise distribution in the evaluate.rs file to ensure correct distribution amounts are returned.

What was done?

  • Renamed the variable steps_passed to era_intervals_passed for clarity.
  • Updated the logic in the stepwise distribution calculation to adjust the range for the distribution based on contract_registration_step.
  • Added handling for the case where x is less than contract_registration_step to return 0 immediately.

How Has This Been Tested?

The changes have been tested through existing unit tests and additional tests have been added to ensure the correctness of stepwise distribution calculations.

Breaking Changes

None

Checklist

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated relevant unit/integration/functional/e2e tests
  • I have added ! to the title and described breaking changes in the corresponding section if my code contains any.

For repository code-owners and collaborators only

  • I have assigned this pull request to a milestone

Summary by CodeRabbit

  • New Features

    • Added support for specifying the contract start block height when creating token contracts in tests.
    • Introduced a new test for stepwise perpetual token distribution, verifying correct reward calculations after time advances.
  • Bug Fixes

    • Improved stepwise distribution logic to return zero rewards for steps before contract registration and adjusted step indexing.
  • Tests

    • Updated all relevant test cases to include the new optional contract start block parameter.
    • Enhanced test coverage for token distribution scenarios, including stepwise distribution.
  • Refactor

    • Improved variable naming for clarity in distribution evaluation logic.

Copy link
Contributor

coderabbitai bot commented May 26, 2025

Walkthrough

The changes update the function signature of create_token_contract_with_owner_identity to accept an optional block height parameter and propagate this through all test calls. The logic for evaluating stepwise and step decreasing perpetual token distribution functions is updated for clarity and correctness, including a new boundary check and key offset in the stepwise variant. A new test for stepwise distribution is added.

Changes

File(s) Change Summary
.../src/execution/validation/state_transition/state_transitions/mod.rs Updated create_token_contract_with_owner_identity to accept contract_start_block: Option<BlockHeight> and use it in contract setup.
.../tests/token/distribution/perpetual/time_based.rs Added test for stepwise distribution; added imports and extra None arguments in function calls.
.../tests/token/distribution/perpetual/block_based.rs
.../tests/token/distribution/pre_programmed.rs
Added extra None argument to create_token_contract_with_owner_identity calls.
.../tests/token/burn/mod.rs
.../tests/token/config_update/mod.rs
.../tests/token/direct_selling/mod.rs
.../tests/token/freeze/mod.rs
.../tests/token/mint/mod.rs
.../tests/token/transfer/mod.rs
Added extra None argument to all create_token_contract_with_owner_identity (and related) calls in tests.
.../tests/document/creation.rs
.../check_tx/v0/mod.rs
.../data_contract_create/mod.rs
Added extra None argument to create_token_contract_with_owner_identity calls in tests.
.../src/data_contract/associated_token/token_perpetual_distribution/distribution_function/evaluate.rs Renamed variable for clarity in StepDecreasingAmount; added boundary check and key offset in Stepwise evaluation logic.

Sequence Diagram(s)

sequenceDiagram
    participant Test
    participant Platform
    participant Contract
    participant DistributionFunction

    Test->>Platform: create_token_contract_with_owner_identity(..., contract_start_block, ...)
    Platform->>Contract: Set created_at_block_height = contract_start_block or 0
    Test->>DistributionFunction: evaluate(x)
    alt Stepwise variant
        DistributionFunction->>DistributionFunction: if x < contract_registration_step return 0
        DistributionFunction->>DistributionFunction: steps.range(..(x - contract_registration_step))
    else StepDecreasingAmount variant
        DistributionFunction->>DistributionFunction: era_intervals_passed = ...
    end
Loading

Possibly related PRs

  • dashpay/platform#2550: Modifies DistributionFunction::evaluate logic for Stepwise and StepDecreasingAmount, closely related to this PR’s focus on evaluation improvements.
  • dashpay/platform#2548: Updates DistributionFunction evaluation logic, encoding, decoding, and adds tests for stepwise and step decreasing variants, directly connected at the code level.

Suggested reviewers

  • shumkov

Poem

In the warren of code, a new path we hop,
With an extra None for each test to adopt.
Stepwise and decreasing, distributions align,
Tokens now flow in a manner divine.
🐇 The block height is set, the tests all agree—
This garden of logic grows bug-free!


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3d5328e and c70733f.

📒 Files selected for processing (14)
  • packages/rs-dpp/src/data_contract/associated_token/token_perpetual_distribution/distribution_function/evaluate.rs (3 hunks)
  • packages/rs-drive-abci/src/execution/check_tx/v0/mod.rs (1 hunks)
  • packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/creation.rs (1 hunks)
  • packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/burn/mod.rs (5 hunks)
  • packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/config_update/mod.rs (14 hunks)
  • packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/direct_selling/mod.rs (4 hunks)
  • packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/distribution/perpetual/block_based.rs (4 hunks)
  • packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/distribution/perpetual/time_based.rs (10 hunks)
  • packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/distribution/pre_programmed.rs (6 hunks)
  • packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/freeze/mod.rs (11 hunks)
  • packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/mint/mod.rs (25 hunks)
  • packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/transfer/mod.rs (7 hunks)
  • packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_create/mod.rs (3 hunks)
  • packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/mod.rs (3 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: QuantumExplorer
PR: dashpay/platform#2257
File: packages/rs-drive-abci/src/mimic/test_quorum.rs:159-164
Timestamp: 2024-11-20T16:16:01.830Z
Learning: QuantumExplorer prefers not to receive auto-generated messages asking to post on social media.
🧬 Code Graph Analysis (2)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/freeze/mod.rs (5)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/burn/mod.rs (3)
  • None (25-25)
  • None (111-111)
  • None (204-204)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/creation.rs (2)
  • None (305-305)
  • None (3662-3662)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/transfer/mod.rs (5)
  • None (41-41)
  • None (142-142)
  • None (809-809)
  • None (900-900)
  • None (1131-1131)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/mint/mod.rs (5)
  • None (26-26)
  • None (112-112)
  • None (291-291)
  • None (379-379)
  • None (468-468)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/mod.rs (1)
  • None (946-946)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/config_update/mod.rs (5)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/burn/mod.rs (3)
  • None (25-25)
  • None (111-111)
  • None (204-204)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/creation.rs (2)
  • None (305-305)
  • None (3662-3662)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/transfer/mod.rs (5)
  • None (41-41)
  • None (142-142)
  • None (809-809)
  • None (900-900)
  • None (1131-1131)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/mint/mod.rs (5)
  • None (26-26)
  • None (112-112)
  • None (291-291)
  • None (379-379)
  • None (468-468)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/mod.rs (1)
  • None (946-946)
⏰ Context from checks skipped due to timeout of 90000ms (20)
  • GitHub Check: Rust packages (dpp) / Tests
  • GitHub Check: Rust packages (dpp) / Unused dependencies
  • GitHub Check: Rust packages (dpp) / Formatting
  • GitHub Check: Rust packages (drive-abci) / Check each feature
  • GitHub Check: Rust packages (dpp) / Linting
  • GitHub Check: Rust packages (dash-sdk) / Check each feature
  • GitHub Check: Rust packages (dash-sdk) / Linting
  • GitHub Check: Rust packages (dash-sdk) / Tests
  • GitHub Check: Rust packages (dash-sdk) / Unused dependencies
  • GitHub Check: Rust packages (drive-abci) / Tests
  • GitHub Check: Rust packages (drive-abci) / Linting
  • GitHub Check: Rust packages (drive) / Tests
  • GitHub Check: Rust packages (drive) / Linting
  • GitHub Check: Rust packages (wasm-dpp) / Tests
  • GitHub Check: Rust packages (wasm-dpp) / Unused dependencies
  • GitHub Check: Rust packages (wasm-dpp) / Linting
  • GitHub Check: Build Docker images (DAPI, dapi, dapi) / Build DAPI image
  • GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
  • GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
  • GitHub Check: Build JS packages / Build JS
🔇 Additional comments (46)
packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/distribution/pre_programmed.rs (6)

50-50: LGTM: Function signature update handled correctly.

The addition of the None parameter for the optional contract_start_block is consistent with the function signature update mentioned in the AI summary.


217-217: LGTM: Consistent parameter addition.

The None parameter addition maintains consistency with the updated function signature.


387-387: LGTM: Consistent parameter addition.

The None parameter addition maintains consistency with the updated function signature.


496-496: LGTM: Consistent parameter addition.

The None parameter addition maintains consistency with the updated function signature.


666-666: LGTM: Consistent parameter addition.

The None parameter addition maintains consistency with the updated function signature.


786-786: LGTM: Consistent parameter addition.

The None parameter addition maintains consistency with the updated function signature.

packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/document/creation.rs (1)

3659-3666: Align test invocation with updated signature
An extra None argument has been added to the call to create_token_contract_with_owner_identity, which matches the new Option<BlockHeight> parameter in its signature. Please verify that the ordering of all parameters (especially the new contract_start_block) corresponds exactly to the updated function definition.

packages/rs-drive-abci/src/execution/check_tx/v0/mod.rs (1)

3661-3661: LGTM: Function signature compatibility update

The addition of None for the new optional contract_start_block parameter correctly maintains compatibility with the updated function signature while preserving existing test behavior.

packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/transfer/mod.rs (1)

44-44: LGTM! Consistent function signature updates.

The mechanical addition of None parameters to all create_token_contract_with_owner_identity calls correctly accommodates the new optional contract_start_block parameter. The changes are consistent across all test cases and maintain backward compatibility.

Also applies to: 145-145, 261-261, 519-519, 812-812, 903-903, 1030-1030

packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/direct_selling/mod.rs (1)

200-200: LGTM! Consistent signature updates across test functions.

All calls to create_token_contract_with_owner_identity have been properly updated with the additional None parameter. The changes maintain test functionality while accommodating the new optional contract_start_block parameter, including the update in the helper function create_token_with_pricing.

Also applies to: 272-272, 391-391, 625-625

packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/data_contract_create/mod.rs (3)

1134-1141: Align tests with updated function signature
The added None argument correctly maps to the new contract_start_block parameter in create_token_contract_with_owner_identity. Tests now compile and exercise the updated API.


2338-2344: Update external-token burn test to include new parameter
In test_data_contract_creation_with_single_token_setting_burn_of_external_token_not_allowed, the inserted None before platform_version aligns with the signature change for the optional start block.


2579-2585: Propagate new optional block parameter in external-token position test
The None placeholder is correctly passed for contract_start_block in test_data_contract_creation_with_single_token_setting_transfer_of_external_token_that_does_not_exist_in_contract_that_does_exist.

packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/mint/mod.rs (1)

29-29: LGTM! Consistent function signature updates across all test cases.

The mechanical addition of None as an additional parameter to all create_token_contract_with_owner_identity function calls is correctly implemented. This maintains backward compatibility while accommodating the new optional contract_start_block parameter that allows tests to specify the block height at which contracts are created.

Also applies to: 115-115, 203-203, 294-294, 382-382, 471-471, 559-559, 656-656, 751-751, 842-842, 942-942, 1040-1040, 1153-1153, 1264-1264, 1377-1377, 1498-1498, 1776-1776, 2099-2099, 2328-2328, 3154-3154, 3269-3269, 3466-3466, 3607-3607

packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/burn/mod.rs (5)

22-30: LGTM: Correct parameter addition for updated function signature.

The addition of the None parameter at line 28 correctly accommodates the new contract_start_block: Option<BlockHeight> parameter in the create_token_contract_with_owner_identity function signature.


108-116: LGTM: Consistent parameter addition.

The None parameter addition at line 114 is consistent with the function signature update.


201-209: LGTM: Consistent parameter addition.

The None parameter addition at line 207 maintains consistency with the updated function signature.


302-329: LGTM: Consistent parameter addition.

The None parameter addition at line 327 correctly follows the established pattern for the function signature update.


564-591: LGTM: Consistent parameter addition.

The None parameter addition at line 589 maintains consistency with all other calls to the updated function.

packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/freeze/mod.rs (11)

26-44: LGTM: Correct parameter addition for updated function signature.

The addition of the None parameter at line 42 correctly accommodates the new contract_start_block: Option<BlockHeight> parameter in the create_token_contract_with_owner_identity function signature.


124-142: LGTM: Consistent parameter addition.

The None parameter addition at line 140 is consistent with the function signature update.


226-253: LGTM: Consistent parameter addition.

The None parameter addition at line 251 maintains consistency with the updated function signature.


394-421: LGTM: Consistent parameter addition.

The None parameter addition at line 419 correctly follows the established pattern for the function signature update.


790-819: LGTM: Consistent parameter addition.

The None parameter addition at line 817 maintains consistency with all other calls to the updated function.


990-1018: LGTM: Consistent parameter addition.

The None parameter addition at line 1016 is consistent with the function signature update.


1086-1114: LGTM: Consistent parameter addition.

The None parameter addition at line 1112 maintains consistency with the updated function signature.


1196-1224: LGTM: Consistent parameter addition.

The None parameter addition at line 1222 correctly follows the established pattern for the function signature update.


1312-1337: LGTM: Consistent parameter addition.

The None parameter addition at line 1335 maintains consistency with all other calls to the updated function.


1560-1598: LGTM: Consistent parameter addition.

The None parameter addition at line 1596 is consistent with the function signature update.


1912-1950: LGTM: Consistent parameter addition.

The None parameter addition at line 1948 maintains consistency with the updated function signature across all test cases.

packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/config_update/mod.rs (1)

45-45: LGTM! Consistent function signature update across all test calls.

These changes correctly add the new optional contract_start_block parameter to all create_token_contract_with_owner_identity function calls. The changes are mechanical, consistent, and properly positioned before the platform_version parameter. Passing None maintains the existing default behavior for all tests.

Also applies to: 149-149, 296-296, 406-406, 560-560, 651-651, 742-742, 839-839, 960-960, 1077-1077, 1292-1292, 1683-1683, 2145-2145, 2895-2895

packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/distribution/perpetual/block_based.rs (4)

59-59: LGTM: Function signature update correctly applied.

The addition of the None parameter aligns with the updated create_token_contract_with_owner_identity function signature to include the optional contract_start_block parameter.


302-302: LGTM: Consistent function signature update.

The None parameter addition is consistent with the updated function signature and maintains existing test behavior.


424-424: LGTM: Function signature update applied consistently.

The change maintains the established pattern and preserves test functionality.


2701-2701: LGTM: Test infrastructure updated correctly.

The function signature update is properly applied to the test suite infrastructure, ensuring all test cases will work correctly with the new function signature.

packages/rs-dpp/src/data_contract/associated_token/token_perpetual_distribution/distribution_function/evaluate.rs (5)

75-75: LGTM: Improved variable naming for clarity.

The rename from steps_passed to era_intervals_passed better describes what the variable represents - the number of era intervals that have passed since the decreasing period started.


80-80: LGTM: Consistent with variable rename.

Updated reference maintains consistency with the renamed variable.


89-89: LGTM: Loop variable updated consistently.

The loop variable reference has been updated to match the renamed variable, maintaining code consistency.


104-106: LGTM: Proper boundary check for contract registration.

The early return when x < contract_registration_step is logically sound - tokens cannot be distributed before the contract is registered. This also prevents potential integer underflow in the subsequent range query calculation.


109-109: LGTM: Stepwise distribution now properly accounts for contract registration timing.

The range query adjustment ..=(x - contract_registration_step) correctly shifts the stepwise distribution indexing to align with the contract registration step. This makes the stepwise distribution behavior consistent with other distribution functions that consider contract_registration_step as their baseline.

Key behavioral change: The stepwise distribution curve now effectively starts at contract_registration_step rather than at time 0, which aligns with the business logic that distributions should begin when the contract is registered.

packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/mod.rs (3)

62-62: LGTM: Import addition is correct.

The BlockHeight import is appropriately added to support the new function parameter.


2338-2338: LGTM: Function parameter addition is well-designed.

The new optional contract_start_block parameter maintains backwards compatibility and follows the established pattern of other optional parameters in the function.


2351-2352: LGTM: Parameter usage is correctly implemented.

The implementation properly handles the optional parameter using unwrap_or_default() and follows the established pattern for similar optional parameters in the function.

packages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/batch/tests/token/distribution/perpetual/time_based.rs (3)

12-12: LGTM: Import addition supports new test functionality.

The import of std::collections::BTreeMap is correctly added to support the new stepwise distribution test that uses BTreeMap::from([...]) syntax.


56-56: LGTM: Function signature updates are consistent.

All calls to create_token_contract_with_owner_identity have been consistently updated to include the new optional contract_start_block parameter. The None values are appropriate for tests that don't need to specify a custom contract start block.

Also applies to: 301-301, 424-424, 541-541, 728-728, 918-918, 1106-1106, 1288-1288


1363-1491: Comprehensive stepwise distribution test with correct calculations.

The new test effectively validates stepwise distribution functionality:

  • Setup: Creates a stepwise distribution with thresholds at steps 5→1 and 50→1000 tokens
  • Timing: 60 intervals (18,000,000ms ÷ 300,000ms) plus initial step = 61 total steps
  • Calculation verification:
    • Steps 0-4: 0 tokens (5 steps)
    • Steps 5-49: 1 token each (45 steps)
    • Steps 50-60: 1000 tokens each (11 steps)
    • Total: 0×5 + 1×45 + 1000×11 = 11,045 tokens ✓

The test correctly uses the contract start block parameter (Some(40)) and start time (Some(10_000_000)) to align with the stepwise calculation logic.

✨ Finishing Touches
  • 📝 Generate Docstrings

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@QuantumExplorer QuantumExplorer changed the title fix: correct stepwise distribution logic in evaluate.rs fix(dpp): correct stepwise distribution logic in evaluate.rs May 26, 2025
@QuantumExplorer QuantumExplorer added this to the v2.0.0 milestone May 26, 2025
Copy link
Member Author

@QuantumExplorer QuantumExplorer left a comment

Choose a reason for hiding this comment

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

Self Reviewed

@QuantumExplorer QuantumExplorer merged commit 52b25a8 into v2.0-dev May 26, 2025
67 checks passed
@QuantumExplorer QuantumExplorer deleted the featfix-stepwise-distribution branch May 26, 2025 06:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant