backport: Merge bitcoin#29227, 27389, 27832, 30215#7202
backport: Merge bitcoin#29227, 27389, 27832, 30215#7202vijaydasmp wants to merge 4 commits intodashpay:developfrom
Conversation
eb78ea4 [log] mempool loading (glozow) Pull request description: Motivated by bitcoin#29193. Currently, we only log something (non-debug) when we fail to load the file and at the end of importing all the transactions. That means it's hard to tell what's happening if it's taking a long time to load. This PR adds a maximum of 10 new unconditional log lines: - When we start to load transactions. - Our progress percentage when it advances by at least 10% from the last time we logged. Percentage is based on the number of transactions. If there are lots of transactions in the mempool, the logs will look like this: ``` 2024-01-11T11:36:30.410726Z Loading 401 mempool transactions from disk... 2024-01-11T11:36:30.423374Z Progress loading mempool transactions from disk: 10% (tried 41, 360 remaining) 2024-01-11T11:36:30.435539Z Progress loading mempool transactions from disk: 20% (tried 81, 320 remaining) 2024-01-11T11:36:30.447874Z Progress loading mempool transactions from disk: 30% (tried 121, 280 remaining) 2024-01-11T11:36:30.460474Z Progress loading mempool transactions from disk: 40% (tried 161, 240 remaining) 2024-01-11T11:36:30.473731Z Progress loading mempool transactions from disk: 50% (tried 201, 200 remaining) 2024-01-11T11:36:30.487806Z Progress loading mempool transactions from disk: 60% (tried 241, 160 remaining) 2024-01-11T11:36:30.501739Z Progress loading mempool transactions from disk: 70% (tried 281, 120 remaining) 2024-01-11T11:36:30.516334Z Progress loading mempool transactions from disk: 80% (tried 321, 80 remaining) 2024-01-11T11:36:30.531309Z Progress loading mempool transactions from disk: 90% (tried 361, 40 remaining) 2024-01-11T11:36:30.549019Z Imported mempool transactions from disk: 401 succeeded, 0 failed, 0 expired, 0 already there, 400 waiting for initial broadcast ``` If there are 0 or 1 transactions, progress logs aren't printed. ACKs for top commit: kevkevinpal: Concept ACK [eb78ea4](bitcoin@eb78ea4) ismaelsadeeq: ACK eb78ea4 dergoegge: Code review ACK eb78ea4 theStack: re-ACK eb78ea4 mzumsande: tested ACK eb78ea4 Tree-SHA512: ae4420986dc7bd5cb675a7ebc76b24c8ee60007f0296ed37e272f1c3415764d44963bea84c51948da319a65661dca8a95eac2a59bf7e745519b6fcafa09812cf
f842ed9 test: refactor: replace unnecessary `BytesIO` uses (Sebastian Falbesoner) Pull request description: Rather than needing to create intermediate stream variables, we can use helper functions like `tx_from_hex` instead or access the result directly, leading both to increased readability and less code. ACKs for top commit: stickies-v: ACK f842ed9 brunoerg: crACK f842ed9 aureleoules: ACK f842ed9 - It seems that these are the only instances that can be changed and it simplifies test code. Tree-SHA512: 7f4fd7a26720d1988bf27f66c817ff6cd7060350a3be62d28e7848c768fd43578719ca475193d4057ccf4f2458af18564fd513fe3a1d458a11c799927c12bd65
✅ No Merge Conflicts DetectedThis PR currently has no conflicts with other open PRs. |
…ize=2 tests faafc35 doc: Clarify that -datacarriersize applies to the full raw scriptPubKey, not the data push (MarcoFalke) 55550e7 test: Add -datacarriersize=2 tests (MarcoFalke) Pull request description: Clarify with a test that `-datacarriersize` applies to the serialized size of the scriptPubKey, not the size of the pushed data. So for example, * `-datacarriersize=2` will reject a `raw(6a01aa)`, even though only one byte is pushed * `-datacarriersize=0` (or `-datacarrier=0`) will reject a `raw(6a)`, even though no byte is pushed * `-datacarriersize=0` (or `-datacarrier=0`) will reject a `raw(6a00)`, even though zero bytes are pushed ACKs for top commit: ajtowns: ACK faafc35 instagibbs: ACK bitcoin@faafc35 Tree-SHA512: f01ace02798f596ac2a02461e9f2a6ef91b3b37c976ea0b3bc860e2d3efb0ace0fd8b779dd18249cee7f84ebbe5fd21d8506afd3a15edadc00b843ff3b4aacc7
…n/json 3c08e11 doc: JSON-RPC request Content-Type is application/json (Luke Dashjr) Pull request description: Specify json content type in RPC examples. Picks up bitcoin#29946. Which needed rebasing and the commit message fixing, ACKs for top commit: laanwj: ACK 3c08e11 tdb3: ACK for 3c08e11 Tree-SHA512: 770bbbc0fb324cb63628980b13583cabf02e75079851850170587fb6eca41a70b01dcedaf1926bb6488eb9816a3cc6616fe8cee8c4b7e09aa39b7df5834ca0ec
WalkthroughThis pull request updates JSON-RPC interface documentation and help text to use the correct Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs). 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. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (3)
src/rpc/util.cpp (1)
222-234: Port number inconsistency betweenHelpExampleRpcandHelpExampleRpcNamed.
HelpExampleRpcon line 223 uses port9998(Dash mainnet RPC), whileHelpExampleRpcNamedon line 234 uses port8332(Bitcoin mainnet RPC). This inconsistency appears to predate this PR but is worth noting since this code is being modified.The content-type change from
text/plaintoapplication/jsonis correct for JSON-RPC requests.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/rpc/util.cpp` around lines 222 - 234, The two example helpers use different hard-coded ports—HelpExampleRpc uses 9998 while HelpExampleRpcNamed uses 8332—so make them consistent: either replace the 9998 in HelpExampleRpc with 8332 to match HelpExampleRpcNamed, or (preferred) use the shared RPC port constant/variable used elsewhere (instead of a literal) in both HelpExampleRpc and HelpExampleRpcNamed so both examples always show the correct configured RPC port.test/functional/mempool_datacarrier.py (2)
33-36: Consider using list unpacking for cleaner syntax.The type hint was removed to accommodate
None, and the concatenation works correctly. However, using unpacking is more idiomatic Python.Proposed changes
- def test_null_data_transaction(self, node: TestNode, data, success: bool) -> None: + def test_null_data_transaction(self, node: TestNode, data: bytes | None, success: bool) -> None: tx = self.wallet.create_self_transfer(fee_rate=0)["tx"] data = [] if data is None else [data] - tx.vout.append(CTxOut(nValue=0, scriptPubKey=CScript([OP_RETURN] + data))) + tx.vout.append(CTxOut(nValue=0, scriptPubKey=CScript([OP_RETURN, *data])))🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/functional/mempool_datacarrier.py` around lines 33 - 36, The test_null_data_transaction function currently builds the OP_RETURN script by concatenating a list ([OP_RETURN] + data) after normalizing data to a list; replace that concatenation with Python list unpacking to be more idiomatic: keep the data normalization (data = [] if data is None else [data]) and construct the CScript using CScript([OP_RETURN, *data]) when creating the CTxOut (refer to test_null_data_transaction, tx.vout.append(CTxOut(...)), CScript and data variables).
30-30: Remove extraneous f-string prefix.This string has no placeholders, so the
fprefix is unnecessary.Proposed fix
- ["-datacarrier=1", f"-datacarriersize=2"], + ["-datacarrier=1", "-datacarriersize=2"],🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/functional/mempool_datacarrier.py` at line 30, The second list element uses an unnecessary f-string (f"-datacarriersize=2") even though there are no placeholders; replace f"-datacarriersize=2" with a plain string "-datacarriersize=2" in the list (e.g., change ["-datacarrier=1", f"-datacarriersize=2"] to ["-datacarrier=1", "-datacarriersize=2"]).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@src/rpc/util.cpp`:
- Around line 222-234: The two example helpers use different hard-coded
ports—HelpExampleRpc uses 9998 while HelpExampleRpcNamed uses 8332—so make them
consistent: either replace the 9998 in HelpExampleRpc with 8332 to match
HelpExampleRpcNamed, or (preferred) use the shared RPC port constant/variable
used elsewhere (instead of a literal) in both HelpExampleRpc and
HelpExampleRpcNamed so both examples always show the correct configured RPC
port.
In `@test/functional/mempool_datacarrier.py`:
- Around line 33-36: The test_null_data_transaction function currently builds
the OP_RETURN script by concatenating a list ([OP_RETURN] + data) after
normalizing data to a list; replace that concatenation with Python list
unpacking to be more idiomatic: keep the data normalization (data = [] if data
is None else [data]) and construct the CScript using CScript([OP_RETURN, *data])
when creating the CTxOut (refer to test_null_data_transaction,
tx.vout.append(CTxOut(...)), CScript and data variables).
- Line 30: The second list element uses an unnecessary f-string
(f"-datacarriersize=2") even though there are no placeholders; replace
f"-datacarriersize=2" with a plain string "-datacarriersize=2" in the list
(e.g., change ["-datacarrier=1", f"-datacarriersize=2"] to ["-datacarrier=1",
"-datacarriersize=2"]).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 0120a33b-a7ca-4afc-a648-f0a6b9fa389c
📒 Files selected for processing (7)
doc/JSON-RPC-interface.mdsrc/init.cppsrc/rpc/util.cppsrc/test/rpc_tests.cppsrc/validation.cpptest/functional/interface_rest.pytest/functional/mempool_datacarrier.py
bitcoin backporting