Merge upstream master into horizon-v2.28.2 to facilitate the back-merge
#5206
Conversation
…dger to be different phrase to avoid conflict with existing 'Processed ledger' log output from fsm (stellar#5155)
…ring ledger ingestion (stellar#5158)
…ellar#5171) * go mod tidy * Add double-close protection * Add request tracking when cache invokes upstream download * Add cache hit tracking * Move stat tracking to a separate file * Modify test to track stats+integrity after caching * Stop double-closing identical XDR stream readers
…lar#5178) * Change logging provider to Horizon's default rather than logrus
…estion processing (stellar#5176)
* Add check for ledger state in txsub * Add test for badSeq * Fix failing unittest * Update system_test.go * Small changes * Update main.go
* services/horizon: Fix claimable balance query * Fix Soroban RPC image incompatibility
…stellar#5197) * Add a `--history-archive-caching` flag (default=true) to toggle behavior * Refactor to use a library: fscache * Hook new metric into prometheus * Add parallel read test to stress cache * Add tests for deadlocking and other misc. scenarios
git switch master
git pull upstream master # sync to stellar/go
git checkout horizon-v2.28.2
git switch -C v2.28.2-backmerge
git merge -S master
# <resolve all conflicts>
git commit -S
git push origin v2.28.2-backmerge
| a.stats.incrementDownloads() | ||
| // // this is a query on the HA server state, not a data/bucket file download | ||
| // a.stats.incrementRequests() |
There was a problem hiding this comment.
this is a diff I'm a little worried about because I'm not sure which is correct. @sreuland you're on the git blame for this so can you help give some insight?
There was a problem hiding this comment.
ugh, this looks like a bad merge conflict resolution, that's not what 2.28.2 looks like in this area.
hmm, when i ported 2.28.0 and 2.28.1 branches back to master, I used interactive rebase instead of merge-master-to-rel-then-merge-rel-back-to-master and found that resulted in less conflicts and easier to understand the remaining ones which did arise from archive pool stuff of light horizon going into master but not not on 2.28 yet
it may be worth re-trying this merge of 2.28.2 to master with a rebase instead just to see - try create new branch off release branch, from that branch git rebase -i master choose just the new commits on the 2.28.2 branch, and see how conflicts look from there, should be a lot less, and should only see the commits relevant to the 2.28.2 show up in git compare to master, whereas this pr is showing a lot of commits
There was a problem hiding this comment.
It's not a bad resolution because I did it on purpose: you can see that on master it has the commented-out lines! I left them both in specifically because I wanted to ensure that the behavior preserved here (i.e. incrementing downloads) is actually the correct one! So can you confirm that? 😄
The merge actually went well otherwise! The conflicts were almost exclusively related to my code in #5197 so I had a good handle on how to resolve everything.
I think the reason why there are so many commits showing here is exactly because you did an interactive rebase, so it still thinks that those commits from .0 and .1 are different than the ones you merged into master (since history got modified). I'll try it via the rebase approach to see if it's cleaner but I also think it's fine as-is since the conflicts got worked out.
There was a problem hiding this comment.
Good call on the interactive rebase - it's a cleaner history! At the expense of authors getting a little murky but that's okay. Please review there, instead ➡️ #5210!
What
I took the following steps:
The rationale is self-explanatory: we need the patch release changes back in master.
Why
Self-explanatory. Replaces #5205.
This was a very precarious merge (lots of conflicts were resolved) so I'd appreciate multiple eyes on it for sanity checking.