Skip to content

Temporarily allow soroban upgrade setup to fail - #181

Merged
SirTyson merged 1 commit into
stellar:mainfrom
SirTyson:classic-max-tps-fix
Jul 15, 2024
Merged

Temporarily allow soroban upgrade setup to fail#181
SirTyson merged 1 commit into
stellar:mainfrom
SirTyson:classic-max-tps-fix

Conversation

@SirTyson

Copy link
Copy Markdown
Contributor

This change allows loadgen to succeed if setting up the Soroboan upgrade contract fails. This is a temporary fix for Max TPS test until we figure out the root cause of the Soroban upgrade bug.

@SirTyson
SirTyson requested a review from bboston7 July 15, 2024 22:55
@SirTyson
SirTyson merged commit 9bd3d8a into stellar:main Jul 15, 2024
Jonathan-Eid added a commit to Jonathan-Eid/supercluster that referenced this pull request Aug 11, 2026
Every run shipped two log files: http_server_<stamp>.log holding the whole
monitor's output, and job_monitor_<stamp>.log holding nothing. Seen in run stellar#181
at 13.27 KiB and 0 B, and reproduced locally.

build_logger calls logging.basicConfig, which is a no-op once the root logger
has handlers. job_monitor imports http_server before configuring itself, so
http_server's call ran first and won; job_monitor's was discarded. The
FileHandler it had already constructed still created and opened its file, which
is why an empty one appeared. Both modules take the ROOT logger, so everything
landed in the file named after whichever module imported first.

The entrypoint should configure logging and nothing else should. http_server now
takes a plain named logger, so job_monitor's build_logger is the first and only
call: one file, job_monitor_<stamp>.log, carrying both modules' records.
Verified -- one file, 276 bytes, records from both.

Image rebuilt as 2026-08-11a and pinned.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants