Add --log-messages-bytes-limit arg to ledger-tool

[andreisilviudragnea]

Problem

agave-ledger-tool supports --geyser-plugin-config option, but not --log-messages-bytes-limit, which can be useful for replaying ledger (using agave-ledger-tool verify, for example) to retrieve truncated logs for txs.

Summary of Changes

Added --log-messages-bytes-limit to all agave-ledger-tool supporting --geyser-plugin-config.

This should be backported to v1.17 and v1.18, because we need it for ledger snapshots created with v1.17.

[steviez]

Change looks fine, argument is identical to the one in validator bin which is ideal. One of these days we'll figure out a better solution to have all of those single-sourced. Added the CI label.

This should be backported to v1.17 and v1.18, because we need it for ledger snapshots created with v1.17.

Why exactly ? If this change lands in master, why can't you just use the tip of master ?

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.8%. Comparing base (03b5965) to head (5456045).

Additional details and impacted files

@@            Coverage Diff            @@
##           master     #854     +/-   ##
=========================================
- Coverage    81.8%    81.8%   -0.1%     
=========================================
  Files         851      851             
  Lines      231744   231744             
=========================================
- Hits       189692   189687      -5     
- Misses      42052    42057      +5     

[andreisilviudragnea]

@steviez I am just following the guidelines from solana-bigtable README. I suppose it is needed to allow replaying the ledger with a version similar to the one when the ledger has been archived.

But it will still be a problem for all intermediate v1.17 versions, because only the latest one will have it (probably v1.17.32). I suppose people can just cherry pick these changes on their local checkout if needed, like I did for v1.17 here.

[steviez]

I am just following the guidelines from solana-bigtable README.

Thanks for the link; while using the same version as what is listed in version.txt is the safest, it is not always strictly necessary. As of late, we have been striving to keep stable/beta/edge versions all consensus and ledger compatible. For example, if you used the latest v1.18 tag or tip of master on the latest epoch backup, I would expect identical replay results between v1.17.31 / v1.18.11 / master. More so, many of the release on any line will not have consensus altering changes. Ie, using v1.17.31 would likely be fine for an upload made from a v1.17.30 warehouse node

But it will still be a problem for all intermediate v1.17 versions, because only the latest one will have it (probably v1.17.32). I suppose people can just cherry pick these changes on their local checkout if needed, like I did for v1.17

Exactly, we can't go back in time and get this commit on all of the old releases. While I mentioned that v1.18 and master should™️ work, cherry-picking the commit on top of the exact tagged commit from the version.txt is probably the safest. This would also be required if you were loading up ledgers that were even older, for example, v1.16 timeframe.

In general, we try to limit backports to items that are deemed "critical" for the cluster (bug fixes, performance regressions, etc) which is why I was opposed to the BP's. We are obviously open to exceptions, but in this case, I think cherry-picking a single commit seems like a pretty reasonable alternative for you

[steviez]

Thanks for the contribution; forgot to hit a button that would allow a few more CI steps to start, letting those go now. Will merge on all greens