Repository navigation
Conversation
When a release pins rs-soroban-env commits that are not public yet, `git submodule update` fails for local builds. Retry once with a one-off `git -c url.<internal>.insteadOf=<public>` rewrite so developers with access to internal-soroban-env can build without editing .gitmodules. Submodules are pinned by hash, so the code fetched is identical either way. The retry disables credential prompts so it fails fast for anyone without access, and nothing is written to git config. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0137rr1HEVwuSp8tysMLYt5q
graydon
approved these changes
Oct 8, 2026
Merged
dappcupsoap
pushed a commit
to dappcupsoap/stellar-core
that referenced
this pull request
Oct 13, 2026
We've had a flaky overlay test breaking CI runs for a while now (most recently https://github.com/stellar/stellar-core/actions/runs/37384282444/job/112013606376?pr=5479 in stellar#5479). The root cause is a test helper that's used in a bunch of places that tries to bypass outbound flow control -- basically to emulate a misbehaving peer sending stuff they shouldn't send -- but doesn't necessarily maintain invariants expected by the flow control subsystem. As a result, one recently-added test has a nondeterministic/racy break of one of the invariants, so the test aborts with an assert failure from time to time. This change renames the test helper method to clarify what it's supposed to be doing, and then modifies what it _does_ to explicitly mark (in test-only code) outgoing messages that are supposed to bypass flow control and then .. just bypasses the flow control including the book-keeping code that has invariants to maintain. At least, this is what sol-and-I discussed and implemented. I am _fairly_ convinced it's correct. It also does seem to get rid of the failure (I ran the test in a loop, crashes before, no more crashes after). But I wouldn't mind careful and conceptual review! I also included here a new, different workaround for the bug I tried but failed to fix in stellar#5462 -- config.status getting stuck reconfiguring with unknown arguments accidentally promoted from gperftools. The previous fix didn't work, but hopefully this one does! I **also** included a fix for **another** flaky test, "ledger state update flow with parallel apply", which has been periodically failing with a simulation timeout.
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
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.
Description
Follow-up to stellar/pipelines#1128. Release commits can now keep
.gitmodulespointed at the publicrs-soroban-envwhile their env commits are still only ininternal-soroban-env, but local builds then fail until the env is public.If
git submodule update --initfails,autogen.shnow retries once with a one-offgit -c url.<internal-soroban-env>.insteadOf=<rs-soroban-env>rewrite. Developers with access build without editing.gitmodules; everyone else fails fast (GIT_TERMINAL_PROMPT=0). Submodules are pinned by hash, so the fetched code is identical, and nothing is written to git config.Tested the submodule block from the real script against local repos: commit public (no retry), internal-only with access (retry succeeds), internal-only without access (exits non-zero), rerun after a partial failure, and no leftover rewrite in local or global config. Not yet tested against GitHub; that needs someone with internal access, plus a check that GitHub Actions still fails while env commits aren't public.
Checklist
clang-formatv8.0.0 (viamake formator the Visual Studio extension) — N/A, shell onlysh -n autogen.shpasses🤖 Generated with Claude Code
https://claude.ai/code/session_0137rr1HEVwuSp8tysMLYt5q
Generated by Claude Code