Skip to content

feat(dashmate): hint to setup a node on start failure - #866

Merged
shumkov merged 3 commits into
v0.24-devfrom
dashmate-help-start
Mar 29, 2023
Merged

feat(dashmate): hint to setup a node on start failure#866
shumkov merged 3 commits into
v0.24-devfrom
dashmate-help-start

Conversation

@shumkov

Copy link
Copy Markdown
Collaborator

Issue being fixed or feature implemented

Sometimes people run dashmate start without knowing that the node configuration is required.

What was done?

  • Remove base config as default
  • Show a hint to run dashmate setup if default config is empty

How Has This Been Tested?

Manually

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 made corresponding changes to the documentation

For repository code-owners and collaborators only

  • I have assigned this pull request to a milestone

@shumkovshumkov added this to the v0.24.0 milestone Mar 28, 2023
@shumkov
shumkov requested a review from antouhou as a code ownerMarch 28, 2023 14:14
Comment threadpackages/dashmate/src/oclif/command/ConfigBaseCommand.js Outdated
Co-authored-by: strophy <32928115+strophy@users.noreply.github.com>
strophy
strophy previously approved these changes Mar 28, 2023
Comment threadpackages/dashmate/src/oclif/command/ConfigBaseCommand.js Outdated
@shumkov
shumkov merged commit 52b7448 into v0.24-devMar 29, 2023
@shumkov
shumkov deleted the dashmate-help-start branch March 29, 2023 02:22
bfoss765 added a commit to bfoss765/platform that referenced this pull request Jul 14, 2026
…edes local dashpay#873 vendor)
Testing dashpay#866+dashpay#851 at gap 30 pending on-device verdict.
Swaps OUR dashpay#846 committed-range fix for hash's alternative
(rust-dashcore PR dashpay#866, `rescan_committed_range`: newly derived scripts
are re-tested against the persisted committed filter range below the
committing batch), adds PR dashpay#851 (the dashpay#649 out-of-order
spend-before-funding UTXO fix), and forces DEFAULT_COINJOIN_GAP_LIMIT to
30 in the vendored third_party/rust-dashcore — to test on-device whether
hash's fixes make the narrower gap viable on the heaviest CoinJoin
wallet, instead of the dashj-parity widening to 100 (dashpay#868).
Vendored tree transform (third_party/rust-dashcore):
- REMOVED our dashpay#846 machinery (drain_committed_rescans /
committed_filters retention across the commit boundary).
- APPLIED PR dashpay#866 (2 commits: 8ccba0b6 rescan committed ranges +
381a4fec defer backward sweep to forward quiescence). Ships its own
coinjoin_gap_discovery_tests.rs — the committed-batch repro
(coinjoin_gap_limit_stall_across_committed_batch) is the GREEN guard
under his mechanism; our identical-scenario port is superseded (same
path, and its setup assumed our retention machinery).
- APPLIED PR dashpay#851 (dashpay#649 out-of-order spend fix; the 27-commit linear
chain only, excluding the dev merges it carried — dashpay#867/dashpay#868/dashpay#877/…).
- DEFAULT_COINJOIN_GAP_LIMIT 100 -> 30, doc rewritten to state the
experiment honestly.
- PRESERVED the asset-lock router fix (CoinJoin + DashPay in the
AssetLock arm of get_relevant_account_types) and rust-dashcore dashpay#863.
Companion test change (packages/rs-platform-wallet/.../asset_lock/build.rs):
coinjoin_gap_limit_discovers_addresses_beyond_the_old_window now tracks
DEFAULT_COINJOIN_GAP_LIMIT (asserts cj.gap_limit() == the constant and
probes far_index = constant - 1) instead of hardcoding 100 / index 50, so
it stays a valid far-edge discovery regression check at any gap; adds
coinjoin_gap_limit_is_experiment_value_30 pinning the compiled constant.
Verification: cargo test green — dash-spv 475, key-wallet 569,
key-wallet-manager 46 (in the standalone clone composite); platform-wallet
438. AAR republished to mavenLocal (org.dashj:dash-sdk-android:0.1.0-SNAPSHOT);
natives carry rescan_committed_range symbols and no drain_committed_rescans.
Known-good dashpay#873/gap-100 AAR backed up at 0.1.0-SNAPSHOT.bak-873-gap100.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
romchornyi pushed a commit that referenced this pull request Aug 25, 2026
Per the decision on the blocker: the pinned branch is re-cut without
#866's `rescan_committed_range`.
Two reasons, and the second is the one that decides it. The Codex finding
stands — the sweep accumulates every match from the birth height into one
`BTreeMap` and queues them together, so an eclipsing compact-filter peer
can turn a full-history rescan into a chain-length allocation followed by
millions of block requests, and nothing upstream bounds it yet.
More decisive is the honest case. On a real long-history CoinJoined
restore the #846 backward sweep ran 191 times, reached a 2.9 GB
footprint, and was killed by jetsam before finishing; the coalescing fix
for that is dashpay/rust-dashcore#974, which is not merged. Shipping #866
without #974 would trade a mid-sync stall for a restore that kills the
app — and long-history migrated wallets are exactly this release's
audience.
What the pin still carries is the point of this PR: #964, #960, #955,
#947 and #946, the six sync-stall fixes, plus #945, #928, #963, #965,
#967, #970 and #980. Dropping #866 restores the status quo of the
previous pin rather than introducing a regression — #846's mid-sync
invisibility was never fixed in what shipped — and the migrated-wallet
heal (#4377) does a full rescan, so it does not lean on this sweep.
#866 and #974 come back together next cycle, with a bounded drain for the
accumulation finding.
Branch: dashpay/rust-dashcore@chore/sync-fixes-without-swept, re-cut at
33030acf (base #945 plus eight cherry-picks, #866 omitted).
Sign up for freeto 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.

2 participants

@shumkov@strophy