Comments (8)
The place where this pops up is:
private async getPacketsFromTxs({
minHeight,
maxHeight,
}: QueryOpts = {}): Promise<PacketWithMetadata[]> {
let query = `send_packet.packet_connection='${this.connectionID}'`;
if (minHeight) {
query = `${query} AND tx.height>=${minHeight}`;
}
if (maxHeight) {
query = `${query} AND tx.height<=${maxHeight}`;
}
const search = await this.client.tm.txSearchAll({ query });
const resultsNested = search.txs.map(({ hash, height, result }) => {
const parsedLogs = logs.parseRawLog(result.log);
// we accept message.sender (cosmos-sdk) and message.signer (x/wasm)
let sender = '';
try {
sender = logs.findAttribute(parsedLogs, 'message', 'sender').value;
} catch {
try {
sender = logs.findAttribute(parsedLogs, 'message', 'signer').value;
} catch {
this.client.logger.warn(
`No message.sender nor message.signer in tx ${toHex(hash)}`
);
}
}
return parsePacketsFromLogs(parsedLogs).map((packet) => ({
packet,
height,
sender,
}));
});
return ([] as PacketWithMetadata[]).concat(...resultsNested);
}
from ts-relayer.
Use the events array instead of the raw log to work around it
This would make it worse most likely, as it would merge the multiple packet events of the same type into one packet. Using raw_log json should keep them as independent events.
Can you attach the JSON out of a raw_log where two ibc packets were emitted in the same tx? It may be a bug in parsing. Having a fixed json to test against would allow us to debug this much quicker
from ts-relayer.
This would make it worse most likely, as it would merge the multiple packet events of the same type into one packet. Using raw_log json should keep them as independent events.
In the events
they are separate. In the logs
they are merged. See tendermint/tendermint#9595. There you also find all the example outputs.
from ts-relayer.
Good to discuss with tendermint/sdk teams.
Not sure the proper way to get anything out of that data.
NB: what is the events
field you refer to? Can you link to eg mintscan to show how this is different than log or raw_log?
from ts-relayer.
In https://gist.github.com/webmaster128/5efcb9de025f05a1cd2d55c22e25eb00 you see the full Tendermint RPC response of this transaction: https://testnet.mintscan.io/juno-testnet/txs/502E6F4AEA3FB185DD894D0DC14E013C45E6F52AC00A0B5224F6876A1CA107DB.
There we get .result.tx_result.log
which IMO contains buggy events. This is what we use for packets from tx search. Then there is .result.tx_result.events
, which contains the events rolled out and complete. Since the events are binary in Tendeermint 0.34, they are base64 encoded here.
The term "raw log" does not exist in Tendermint. It was introduced at a higher level (the old LCD API?) there Tendermint's log
was parsed into log
and copied into raw_log
. We inherited that in CosmJS when propagating Tendermint data to higher levels: rawLog: tx.result.log || "",
.
from ts-relayer.
Yes, we should use (and properly parse) tendermint events. This seems to have improved since 2 years ago, when those were not very reliable.
Are these returned / processed properly in CosmJS? If they are, let's use them. If not, let's add those to next CosmJS release and then add them. I think we only support modern tendermint rpc endpoints now, so this should be a safe change. We support tendermint 0.34 (and soon 0.37?)
from ts-relayer.
Okay, it seems that BroadcastTxCommitResponse.deliverTx includes [TxData.events] (https://github.com/cosmos/cosmjs/blob/51a7214d0117351529bed7342078be066d489d5e/packages/tendermint-rpc/src/tendermint34/responses.ts#L200)
It would be good to update ts-relayer to use this, if this is now most reliable source of data.
I never really likes raw_log parsing, but that was the best source a while ago
from ts-relayer.
I think that can be done. I'll check it out.
from ts-relayer.
Related Issues (20)
- Socket hang up HOT 3
- Use osmosis, Gaia, wasmd in CI
- error while setting the IBC , HOT 1
- Error curl: (6) Could not resolve host: faucet.oysternet.cosmwasm.com
- Document using ts-relayer for integration tests HOT 2
- Discord faucet link expired HOT 1
- error: registry.yaml validation failed. HOT 2
- Want local-juno config HOT 3
- Release build of 0.6.0 outdated HOT 1
- feature: Ability to output in `json` from `ibc-setup` HOT 3
- Key management improvements HOT 6
- Use newer / more common test framework HOT 2
- Remove log parsing (parsePacketsFromLogs 🚮)
- Limit number of packets per transaction HOT 1
- error: Query failed with (6) HOT 1
- Restore Browser Compatibility HOT 2
- Don't relay packets from other clients/connections HOT 3
- Error using `timeoutPackets()` in v0.12.0
- Hello, Team HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ts-relayer.