-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Catch the "hooks" branch up with "develop" with a big ol' merge #4927
Open
ximinez
wants to merge
506
commits into
XRPLF:hooks
Choose a base branch
from
ximinez:hooks-merge
base: hooks
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+185,998
−121,302
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently, the `BUILD.md` instructions suggest using `.build` as the build directory, so this change helps to reduce confusion. An alternative would be to instruct developers to add `/.build/` to `.git/info/exclude` or to user-level `.gitignore` (although the latter is very intrusive). However, it is being added here because it is a good practice to have a sensible default that's consistent with the build instructions.
A few methods, including `book_offers`, take currency codes as parameters. The XRPL doesn't care if the letters in those codes are lowercase or uppercase, as long as they come from an alphabet defined internally. rippled doesn't care either, when they are submitted in a hex representation. When they are submitted in an ASCII string representation, rippled, but not XRPL, is more restrictive, preventing clients from interacting with some currencies already in the XRPL. This change gets rippled out of the way and lets clients submit currency codes in ASCII using the full alphabet. Fixes XRPLF#4112
Fix the Windows build by using `unsigned int` (instead of `uint`). The error, introduced by XRPLF#4618, looks something like: rpc\impl\RPCHelpers.h(299,5): error C2061: syntax error: identifier 'uint' (compiling source file app\ledger\Ledger.cpp)
…LF#4410) Amendment "flapping" (an amendment repeatedly gaining and losing majority) usually occurs when an amendment is on the verge of gaining majority, and a validator not in favor of the amendment goes offline or loses sync. This fix makes two changes: 1. The number of validators in the UNL determines the threshold required for an amendment to gain majority. 2. The AmendmentTable keeps a record of the most recent Amendment vote received from each trusted validator (and, with `trustChanged`, stays up-to-date when the set of trusted validators changes). If no validation arrives from a given validator, then the AmendmentTable assumes that the previously-received vote has not changed. In other words, when missing an `STValidation` from a remote validator, each server now uses the last vote seen. There is a 24 hour timeout for recorded validator votes. These changes do not require an amendment because they do not impact transaction processing, but only the threshold at which each individual validator decides to propose an EnableAmendment pseudo-transaction. Fix XRPLF#4350
Modify the `XChainBridge` amendment. Before this patch, two door accounts on the same chain could could own the same bridge spec (of course, one would have to be the issuer and one would have to be the locker). While this is silly, it does not violate any bridge invariants. However, on further review, if we allow this then the `claim` transactions would need to change. Since it's hard to see a use case for two doors to own the same bridge, this patch disallows it. (The transaction will return tecDUPLICATE).
Update minimum compiler requirement for building the codebase. The feature "using enum" is required. This feature was introduced in C++20. Updating the C++ compiler to version 11 or later fixes this error: ``` Building CXX object CMakeFiles/xrpl_core.dir/src/ripple/protocol/impl/STAmount.cpp.o /build/ripple/binary/src/ripple/protocol/impl/STAmount.cpp: In lambda function: /build/ripple/binary/src/ripple/protocol/impl/STAmount.cpp:1577:15: error: expected nested-name-specifier before 'enum' 1577 | using enum Number::rounding_mode; | ^~~~ ``` Fix XRPLF#4693
Address a stack-use-after-scope issue when using rvalues with `soci::use`. Replace rvalues with lvalues to ensure the scope extends beyond the end of the expression. The issue arises from `soci` taking a reference to the rvalue without copying its value or extending its lifetime. `soci` references rvalues in `soci::use_container` and then the address in `soci_use_type`. For types like `int`, memory access post-lifetime is unlikely to cause issues. However, for `std::string`, the backing heap memory can be freed and potentially reused, leading to a potential segmentation fault. This was detected on x86_64 using clang-15 with asan. asan confirms resolution of the issue. Fix XRPLF#4675
Make transactions and pseudo-transactions share the same commonFields again. This regularizes the code in a nice way. While this technically allows pseudo-transactions to have a TicketSequence field, pseudo-transactions are only ever constructed by code paths that don't add such a field, so this is not a transaction processing change. It may be possible to add a separate check to ensure TicketSequence (and other fields that don't make sense on pseudo-transactions) are never added to pseudo-transactions, but that should not be necessary. (TicketSequence is not the only common field that can not and does not appear in pseudo-transactions.) Note: TicketSequence is already documented as a common field. Related: XRPLF#4637 Fix XRPLF#4714
When a new transactor is added, there are several places in applySteps that need to be modified. This patch refactors the code so only one function needs to be modified.
…F#4721) Context: The `DisallowIncoming` amendment provides an option to block incoming trust lines from reaching your account. The asfDisallowIncomingTrustline AccountSet Flag, when enabled, prevents any incoming trust line from being created. However, it was too restrictive: it would block an issuer from authorizing a trust line, even if the trust line already exists. Consider: 1. Issuer sets asfRequireAuth on their account. 2. User sets asfDisallowIncomingTrustline on their account. 3. User submits tx to SetTrust to Issuer. At this point, without `fixDisallowIncomingV1` active, the issuer would not be able to authorize the trust line. The `fixDisallowIncomingV1` amendment, once activated, allows an issuer to authorize a trust line even after the user sets the asfDisallowIncomingTrustline flag, as long as the trust line already exists.
P2P link compression is a feature added in 1.6.0 by XRPLF#3287. https://xrpl.org/enable-link-compression.html If the default changes in the future - for example, as currently proposed by XRPLF#4387 - the comment will be updated at that time. Fix XRPLF#4656
* Add a new API Changelog section for release 1.10. * Mark `jss::fee_ref` as deprecated. * Fix a copy-paste error in one of the unit tests.
Artifactory support was added to the `nix` builds with XRPLF#4556. This extends that support to the Windows build. Now the Windows build works; CI will build and test a Windows release build. This only affects CI and does not change any C++ code. * Copy the remote setup step outcome fix from XRPLF#4716 discussion * Allow the Windows job to succeed if tests fail: * Currently the tests do not always pass, even on a single threaded run on the GitHub runners. So we are using parallel runs and mark the test step as allowed to fail (continue-on-error). * At this point, it's more important that the build succeeds than that the tests succeed, because: * We've got plenty of test coverage on the other jobs. * Test failures are much rarer than build failures because of cross-platform issues. * Having a test failure locally doesn't interrupt a workflow nearly as much as a build failure. Note that Conan Center cannot hold the binaries we need. They do not build the configurations we need, and they will not add them. ## Future Tasks This introduces a new bottleneck since the build and test takes over an hour. Speed up the job by: * Making this job run on heavy Windows runners. * Increasing the number of hardware threads.
…#4746) Update the nix CI runner. This commit does not modify any source code files. The unix builds were successful, but the binaries were not uploaded to the internal artifactory. This PR borrows an idea from @ximinez to attempt to fix this issue. After successful authentication, the `outcome` variable contains a string. In the upload step, we are checking if outcome == 'success' as a prerequisite for uploading the binary. This commit updates the contents of the `outcome` variable.
The assert is saying that the only reason `pathFinder` would be null is if the request was aborted (connection dropped, etc.). That's what `continueCallback()` checks. But that is very clearly not true if you look at `getPathFinder`, which calls `findPaths`, which can return false for many reasons. Fix XRPLF#4744
In Windows, we need to call `python` in order for the `pip` upgrade command to work. This changes the GitHub Actions Windows CI job to use the correct command to upgrade PIP, fixing this error: ``` ERROR: To modify pip, please run the following command: C:\hostedtoolcache\windows\Python\3.9.13\x64\python.exe -m pip install --upgrade pip ``` A future task is to make job run on heavy Windows runners so that it doesn't take so long. Context: XRPLF#4596
It might be possible for the server code to indirect through certain `end()` iterators. While a debug build would catch this problem with `assert()`s, a release build would crash. If there are problems in this area in the future, it is best to get a definitive indication of the nature of the error regardless of whether it's a debug or release build. To accomplish this, these `assert`s are converted into `LogicError`s that will produce a reasonable error message when they fire.
…#4559) The old name was `tecHOOK_ERROR`
Implement native support for W3C DIDs. Add a new ledger object: `DID`. Add two new transactions: 1. `DIDSet`: create or update the `DID` object. 2. `DIDDelete`: delete the `DID` object. This meets the requirements specified in the DID v1.0 specification currently recommended by the W3C Credentials Community Group. The DID format for the XRP Ledger conforms to W3C DID standards. The objects can be created and owned by any XRPL account holder. The transactions can be integrated by any service, wallet, or application.
Add a new RPC / WS call for `server_definitions`, which returns an SDK-compatible `definitions.json` (binary enum definitions) generated by the server. This enables clients/libraries to dynamically work with new fields and features, such as ones that may become available on side chains. Clients query `server_definitions` on a node from the network they want to work with, and immediately know how to speak that node's binary "language", even if new features are added to it in the future (as long as there are no new serialized types that the software doesn't know how to serialize/deserialize). Example: ```js > {"command": "server_definitions"} < { "result": { "FIELDS": [ [ "Generic", { "isSerialized": false, "isSigningField": false, "isVLEncoded": false, "nth": 0, "type": "Unknown" } ], [ "Invalid", { "isSerialized": false, "isSigningField": false, "isVLEncoded": false, "nth": -1, "type": "Unknown" } ], [ "ObjectEndMarker", { "isSerialized": false, "isSigningField": true, "isVLEncoded": false, "nth": 1, "type": "STObject" } ], ... ``` Close XRPLF#3657 --------- Co-authored-by: Richard Holland <[email protected]>
The Network ID logic should not be applied to pseudo-transactions. This allows amendments to enable on a network with an ID > 1024. Context: - NetworkID: XRPLF#4370 - Pseudo-transactions: https://xrpl.org/pseudo-transaction-types.html Fix XRPLF#4736 --------- Co-authored-by: RichardAH <[email protected]>
The unity build speeds up compilation by bundling multiple source files into one larger file. This reduces Windows CI build time by up to 50%. As described in XRPLF#4596, the automatic Windows builds take a very long time. Unity builds are significantly faster - currently about 45 min, much closer to the typical MacOS (35-40 minutes) and nix (~30 minutes) run times. This is intended as a stopgap solution until a more resourced and reliable runner is available. No C++ code was changed. This only affects CI.
Implements a CI workflow that detects when a new version of libxrpl is proposed, uploads it to artifactory under the `clio` channel and notifies Clio's CI to check this newly proposed version.
* Add "doxygen" to list of supported branches to allow for testing and development. * Add titles / H1 to some .md files that don't have them.
* upstream/develop: chore: Fix documentation generation job: (5091) chore: libxrpl verification on CI (5028)
Co-authored-by: Elliot Lee <[email protected]>
* Log when duplicate concurrent inbound ledger are filtered. * RAII for containers that track concurrent inbound ledger. * Comment on when to asynchronously acquire inbound ledgers, which is possible to be always OK, but should have further review. * Other small logging changes Co-authored-by: Ed Hennis <[email protected]>
* refactor filtering of validations to specifically avoid concurrent checkAccept() calls for the same validation ledger hash. * Log when duplicate concurrent validation requests are filtered. * RAII for containers that track concurrent validation requests.
* upstream/master: Set version to 2.2.2 Allow only 1 job queue slot for each validation ledger check Allow only 1 job queue slot for acquiring inbound ledger. Track latencies of certain code blocks, and log if they take too long
* upstream/develop: docs: Update options documentation (5083) refactor: Remove dead headers (5081) refactor: Remove reporting mode (5092)
* upstream/develop: Update Release Notes for 2.2.1 and 2.2.2 Set version to 2.2.2 Allow only 1 job queue slot for each validation ledger check Allow only 1 job queue slot for acquiring inbound ledger. Track latencies of certain code blocks, and log if they take too long
* Retry some failed RPC connections / commands in unit tests * Remove orphaned `getAccounts` function Co-authored-by: John Freeman <[email protected]>
* upstream/develop: test: Retry RPC commands to try to fix MacOS CI jobs (5120)
When rippled initiates a connection to SQLite3, rippled sends a "PRAGMA" statement defining the maximum number of pages allowed in the database. Update the max_page_count so it is consistent with the default for newer versions of SQLite3. Increasing max_page_count is critical for keeping full history servers online. Fix XRPLF#5102
Signed-off-by: luozexuan <[email protected]>
…F#5096) Update book_changes RPC to reduce latency, add "validated" field, and accept shortcut strings (current, closed, validated) for ledger_index. `"validated": true` indicates that the transaction has been included in a validated ledger so the result of the transaction is immutable. Fix XRPLF#5033 Fix XRPLF#5034 Fix XRPLF#5035 Fix XRPLF#5036 --------- Co-authored-by: Bronek Kozicki <[email protected]>
The page_size will soon be made configurable with XRPLF#5135, making this re-ordering necessary. When opening SQLite connection, there are specific pragmas set with commonPragmas. In particular, PRAGMA journal_mode creates journal file and locks the page_size; as of this commit, this sets the page size to the default value of 4096. Coincidentally, the hardcoded page_size was also 4096, so no issue was noticed.
Make page_size and journal_size_limit configurable values in rippled.cfg
* upstream/develop: Set version to 2.3.0-b4 feat(SQLite): allow configurable database pragma values (5135) refactor: re-order PRAGMA statements (5140) fix(book_changes): add "validated" field and reduce RPC latency (5096) chore: fix typos in comments (5094) Set version to 2.2.3 Update SQLite3 max_page_count to match current defaults (5114)
ximinez
force-pushed
the
hooks-merge
branch
from
September 30, 2024 19:42
5e761bc
to
fa9d31a
Compare
Move the newest information to the top, i.e., use reverse chronological order within each of the two sections ("API Versions" and "XRP Ledger server versions")
Validator operators have been confused by the rpcInternal error, which can occur if the server is not running in another process.
* upstream/develop: Expand Error Message for rpcInternal (4959) docs: clean up API-CHANGELOG.md (5064)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
High Level Overview of Change
Note that this is not fully functional code! It is being merged into the
hooks
branch, which is still "in-development".This branch merges
develop
intohooks
, and makes some fixes / updates to get it partially working.Results by OS:
AccountSet
.wasmedge
dependency using Conan. All of the errors appear to be limited toapplyHook.cpp
, and all appear to be due to parsing / preprocessing errors with the massively complex macros inmacros.h
dyld[6586]: Library not loaded: /opt/homebrew/opt/llvm/lib/libLLVM.dylib Referenced from: <68C35517-5F51-3521-A8EE-2CE9D9882E28> /Users/ed/.conan/data/wasmedge/0.9.0/_/_/package/72521513b9fee5d76bcfd97cf0256cfa56cb3897/lib/libwasmedge_c.dylib
I have made no significant effort to fix any remaining issues, and I don't intend to, though I will be happy to accept contributions. This is not intended to be working code, just to get the branch caught up so that someone else can get it working.
Context of Change
This is a follow up to #4225, which also only affected that branch.
Type of Change
Future Tasks
Significant work and debugging needs to be done to get this "ready for prime time".
Note that this is not fully functional code! It is being merged into the
hooks
branch, which is still "in-development".