Add streaming load test backend#590
Draft
aditya1702 wants to merge 22 commits into
Draft
Conversation
…treaming-loadtest backend Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…streaming-loadtest backend option Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…m constructor NewStreamingLoadtestLedgerBackend now, when ArchiveURL is set, opens the meta FIFO and drains frames until the history archive reports a non-zero currentLedger (AND we've consumed a frame with seq >= that checkpoint). This resolves a startup deadlock where apply-load blocks on FIFO writes before publishing the first archive checkpoint, and wallet-backend's PopulateAccountTokens path can't proceed without a valid checkpoint. The drain happens in the constructor (before PrepareRange) because startLiveIngestion calls GetLatestLedgerSequence + PopulateAccountTokens before PrepareRange. Also: lint/errcheck cleanup — errors.Is for io.EOF, wrapped external errors, removed unnecessary uint32 casts on xdr.LedgerCloseMeta.LedgerSequence (which is already uint32). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
aditya1702
force-pushed
the
feature/add-load-test-backend
branch
from
April 22, 2026 15:08
c91d02d to
a701d10
Compare
Bump github.com/stellar/go-stellar-sdk from v0.1.0 to v0.5.0. The new SDK requires Go 1.25, so the Go toolchain moves to 1.25.9 (latest patch) across go.mod, the Dockerfile base image (also migrating from Debian bullseye to bookworm), and the CI workflow. Transitive effect: github.com/stellar/go-xdr advances alongside the SDK, and several golang.org/x/* modules move to patch releases compatible with Go 1.25. No application code changes required -- the SDK's public surface remained backwards-compatible across v0.1 to v0.5.
…vulncheck - x/tools cluster (goimports, shadow, deadcode): v0.31.0 -> v0.43.0 - gqlgen: v0.17.76 -> v0.17.88 (requires Go 1.25) - gotestsum (CI): v1.11.0 -> v1.13.0 - gofumpt: add a pinned auto-install guard at v0.9.2 to match the pattern used by the other tools in the Makefile - Remove the govulncheck target and its entry in the `check` aggregator. Vulnerability scanning can be reintroduced via Dependabot or osv-scanner in a separate change if desired. exhaustive (v0.12.0) and golangci-lint (v2.1.2) are already current and remain unchanged.
Replace builder.WriteString(fmt.Sprintf(...)) with fmt.Fprintf(&builder, ...) across internal/data SQL query builders and the integrationtests useCase summary formatter. strings.Builder implements io.Writer, so Fprintf writes directly without an intermediate string allocation. These lint findings appeared after the Go toolchain bump to 1.25.9. Autofixed via `golangci-lint run --fix`.
The standalone github.com/nishanths/exhaustive/cmd/exhaustive@v0.12.0 binary transitively requires golang.org/x/tools@v0.15.0, which fails to compile under Go 1.25 (a stricter constant-evaluation rule rejects an older pattern in x/tools/internal/tokeninternal). The exhaustive project has had no new release in ~2 years and its master branch has the same problem. golangci-lint v2.1.2 ships its own vendored exhaustive analyzer and builds cleanly under Go 1.25, so move the enforcement there: - Remove the standalone exhaustive Makefile target and its entry in the `check` aggregator. - Remove the standalone exhaustive step in the GitHub Actions go.yaml workflow. - Enable the exhaustive linter in .golangci.yml with the same `default-signifies-exhaustive: true` setting the standalone tool used. Coverage is preserved -- the golangci-lint pass at `make check` now reports zero exhaustive findings, matching the previous state.
Regenerated via `make gql-generate` after bumping gqlgen from v0.17.76 to v0.17.88. The new version produces substantially smaller output (~7800 deletions, ~3500 insertions in generated.go) and also applies gofumpt v0.9's type-block consolidation to the resolver stubs. No behaviour changes -- schema and resolver signatures are unchanged. Regeneration is idempotent: a second `make gql-generate` produces no diff.
When the `exhaustive` step was removed in an earlier commit, the leading whitespace of the following `deadcode` step's `- name:` line was trimmed to column 1, breaking the YAML at parse time. GitHub Actions treated the entire `Go` workflow as invalid and skipped it on this PR (the two checks that appeared were from a separate CodeQL workflow). Restore the 6-space indentation so the step nests correctly under `jobs.check.steps`.
gqlgen's raw output groups all imports in one block, which violates the repo's `github.com/stellar/wallet-backend` local-prefix convention. The `make tidy` target runs goimports with the local prefix to split the imports into third-party / local groups, but the CI workflow runs goimports as a standalone check step (not via `make tidy`), so it catches any post-regen imports that were not normalized. Apply `goimports -local github.com/stellar/wallet-backend -w` to the three regenerated files (generated.go, account.resolvers.go, queries.resolvers.go).
…hive checkpoint The constructor drains the pipe to unstick apply-load until the history archive publishes a checkpoint. Previously those drained frames were discarded, and the ingest loop then started at the archive checkpoint and hit a sequence mismatch because the pipe had already advanced past that ledger. Now the drain retains every frame it reads, trims the retained slice to start at the archive checkpoint once published, and GetLedger replays the buffered frames before resuming pipe reads. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.