Skip to content

Commit c127621

Browse files
raymondkfcheungraymondkfcheung
committed
Reorder the content
1 parent a90cf8e commit c127621

File tree

2 files changed

+77
-77
lines changed

2 files changed

+77
-77
lines changed

‎llms.txt‎

Lines changed: 54 additions & 54 deletions
Original file line numberDiff line numberDiff line change
@@ -28182,59 +28182,6 @@ These two fields now match on new runtimes (`stable2503-5` or later).
2818228182
<span data-ty>✅ Message ID matched.</span>
2818328183
</div>
2818428184

28185-
### Failure Event Handling
28186-
28187-
When an XCM fails, the entire execution is **rolled back**, so no failure events are emitted on-chain. However, you can still observe and debug the failure using two main approaches:
28188-
28189-
#### View Nested Errors from Indexers
28190-
28191-
Most indexers (and API responses) will show **nested dispatch errors** such as:
28192-
28193-
<div class="termynal" data-termynal>
28194-
<pre data-ty>
28195-
"error": {
28196-
"type": "Module",
28197-
"value": {
28198-
"type": "PolkadotXcm",
28199-
"value": {
28200-
"type": "LocalExecutionIncompleteWithError",
28201-
"value": {
28202-
"index": 0,
28203-
"error": {
28204-
"type": "FailedToTransactAsset"
28205-
}
28206-
}
28207-
}
28208-
}
28209-
}
28210-
</pre>
28211-
</div>
28212-
28213-
This output is available on runtimes from **`stable2506` or later**, and is often sufficient for identifying common issues like missing assets or execution limits.
28214-
28215-
#### Use Chopsticks for Full Error Logs
28216-
28217-
For deeper analysis:
28218-
28219-
- Use Chopsticks to **replay the message with logging enabled**
28220-
- See exactly **which instruction failed**, and why
28221-
- View full error chains like `FailedToTransactAsset`, or `AssetNotFound`
28222-
28223-
This is especially useful when dealing with:
28224-
28225-
- Multi-hop XCMs
28226-
- Custom asset locations
28227-
- Execution mismatches or weight issues
28228-
28229-
→ For replay setup, see [Replay and Dry Run XCMs Using Chopsticks](/tutorials/interoperability/replay-and-dry-run-xcms/){target=\_blank}.
28230-
28231-
#### Recommended Debugging Workflow
28232-
28233-
1. **Start with indexer or API output** to inspect dispatch errors.
28234-
2. If unclear, **replay using Chopsticks** to trace message steps.
28235-
3. **Inspect logs** to pinpoint the failing instruction and error.
28236-
4. Adjust asset location, weight, or execution logic accordingly.
28237-
2823828185
## Workaround for Older Runtimes
2823928186

2824028187
* On **older runtimes** (prior to `stable2503-5`), the `message_id` seen in downstream `Processed` events is **not the original topic hash**, but rather a **derived `forwarded_id`**.
@@ -28287,7 +28234,60 @@ if (forwardedIdHex === expectedForwardedId) {
2828728234
`message_id == original_id`
2828828235

2828928236
* ⚠️ **Old runtimes**:
28290-
`message_id == blake2_256("forward_id_for" + original_id)`
28237+
`message_id == blake2_256("forward_id_for" + original_id)` reb
28238+
28239+
### Failure Event Handling
28240+
28241+
When an XCM fails, the entire execution is **rolled back**, so no failure events are emitted on-chain. However, you can still observe and debug the failure using two main approaches:
28242+
28243+
#### View Nested Errors from Indexers
28244+
28245+
Most indexers (and API responses) will show **nested dispatch errors** such as:
28246+
28247+
<div class="termynal" data-termynal>
28248+
<pre data-ty>
28249+
"error": {
28250+
"type": "Module",
28251+
"value": {
28252+
"type": "PolkadotXcm",
28253+
"value": {
28254+
"type": "LocalExecutionIncompleteWithError",
28255+
"value": {
28256+
"index": 0,
28257+
"error": {
28258+
"type": "FailedToTransactAsset"
28259+
}
28260+
}
28261+
}
28262+
}
28263+
}
28264+
</pre>
28265+
</div>
28266+
28267+
This output is available on runtimes from **`stable2506` or later**, and is often sufficient for identifying common issues like missing assets or execution limits.
28268+
28269+
#### Use Chopsticks for Full Error Logs
28270+
28271+
For deeper analysis:
28272+
28273+
- Use Chopsticks to **replay the message with logging enabled**
28274+
- See exactly **which instruction failed**, and why
28275+
- View full error chains like `FailedToTransactAsset`, or `AssetNotFound`
28276+
28277+
This is especially useful when dealing with:
28278+
28279+
- Multi-hop XCMs
28280+
- Custom asset locations
28281+
- Execution mismatches or weight issues
28282+
28283+
→ For replay setup, see [Replay and Dry Run XCMs Using Chopsticks](/tutorials/interoperability/replay-and-dry-run-xcms/){target=\_blank}.
28284+
28285+
#### Recommended Debugging Workflow
28286+
28287+
1. **Start with indexer or API output** to inspect dispatch errors.
28288+
2. If unclear, **replay using Chopsticks** to trace message steps.
28289+
3. **Inspect logs** to pinpoint the failing instruction and error.
28290+
4. Adjust asset location, weight, or execution logic accordingly.
2829128291
--- END CONTENT ---
2829228292

2829328293
Doc-Content: https://docs.polkadot.com/tutorials/interoperability/xcm-transfers/from-relaychain-to-parachain/

‎tutorials/interoperability/xcm-observability.md‎

Lines changed: 23 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -136,6 +136,29 @@ These two fields now match on new runtimes (`stable2503-5` or later).
136136

137137
--8<-- 'code/tutorials/interoperability/xcm-observability/limited-reserve-transfer-assets-result.html'
138138

139+
## Workaround for Older Runtimes
140+
141+
* On **older runtimes** (prior to `stable2503-5`), the `message_id` seen in downstream `Processed` events is **not the original topic hash**, but rather a **derived `forwarded_id`**.
142+
* This `forwarded_id` is computed as:
143+
144+
```rust
145+
fn forward_id_for(original_id: &XcmHash) -> XcmHash {
146+
(b"forward_id_for", original_id).using_encoded(sp_io::hashing::blake2_256)
147+
}
148+
```
149+
150+
To reliably trace messages across **mixed-version chains**, indexers and tools should **check for both `original_id` and its forwarded form**.
151+
152+
```ts
153+
--8<-- 'code/tutorials/interoperability/xcm-observability/forward-id-for.ts'
154+
```
155+
156+
* ✅ **New runtimes**:
157+
`message_id == original_id`
158+
159+
* ⚠️ **Old runtimes**:
160+
`message_id == blake2_256("forward_id_for" + original_id)`
161+
139162
### Failure Event Handling
140163

141164
When an XCM fails, the entire execution is **rolled back**, so no failure events are emitted on-chain. However, you can still observe and debug the failure using two main approaches:
@@ -170,26 +193,3 @@ This is especially useful when dealing with:
170193
2. If unclear, **replay using Chopsticks** to trace message steps.
171194
3. **Inspect logs** to pinpoint the failing instruction and error.
172195
4. Adjust asset location, weight, or execution logic accordingly.
173-
174-
## Workaround for Older Runtimes
175-
176-
* On **older runtimes** (prior to `stable2503-5`), the `message_id` seen in downstream `Processed` events is **not the original topic hash**, but rather a **derived `forwarded_id`**.
177-
* This `forwarded_id` is computed as:
178-
179-
```rust
180-
fn forward_id_for(original_id: &XcmHash) -> XcmHash {
181-
(b"forward_id_for", original_id).using_encoded(sp_io::hashing::blake2_256)
182-
}
183-
```
184-
185-
To reliably trace messages across **mixed-version chains**, indexers and tools should **check for both `original_id` and its forwarded form**.
186-
187-
```ts
188-
--8<-- 'code/tutorials/interoperability/xcm-observability/forward-id-for.ts'
189-
```
190-
191-
* ✅ **New runtimes**:
192-
`message_id == original_id`
193-
194-
* ⚠️ **Old runtimes**:
195-
`message_id == blake2_256("forward_id_for" + original_id)`

0 commit comments

Comments
 (0)