clockworklabs
Bug: `spacetime logs -f` doesn't show you the latest
Today this was reproduced using BitCraft and wasted quite a lot of the SpacetimeDB team's time and the BitCraft team's time. This issue exists in 0.11.1 and we must make sure this either has been fixed in 0.12.0 or will be fixed in 1.0.
BitCraft commit: 1f94ac7cfda88184a8ff7b2816e0306d67db92cd
BitCraftClient commit: 5291f70c97e690cb6bba2a307201498a926246c6
SpacetimeDB commit: 4ffaa2afc9a503c2538341e44fa71f1a8ae99375
There may be some confouding factors here. The bug did not appear when testing locally but did appear when testing against a remote machine.
There may be some confouding factors here.
Just to add, SpacetimeDB was running within a Docker container on the remote machine.
@kurtismullins @jdetter is the repro that you run spacetime logs -f and it immediately doesn't show the latest, or that new logs don't always show up for an existing running spacetime logs -f?
From John on Oct 7:
The solution here was the there was no bug on the spacetimedb side, this is a known bug in the CLI which seems to still exist in 0.11.1 which we must fix for 1.0. Essentially
spacetime logs -f <module-name>for some reason does not fully display the bottom of the log and it does not print new logs. You can see the entire log by doing something likespacetime logs -f <module-name> 100000.
From John on Oct 7:
The solution here was the there was no bug on the spacetimedb side, this is a known bug in the CLI which seems to still exist in 0.11.1 which we must fix for 1.0. Essentially
spacetime logs -f <module-name>for some reason does not fully display the bottom of the log and it does not print new logs. You can see the entire log by doing something likespacetime logs -f <module-name> 100000.
Super helpful, thank you!
I fail to repro this, using [release/v0.11.1-beta]: Manually apply open PR #1632: smoketests: Test unauthorized publish without -c (4ffaa2afc9a503c2538341e44fa71f1a8ae99375), then also with master cccadd10eebf95f46ee63d7e94a6b112fbef45fb.
I run it with docker, setup 2 machines, and use wifi instead of a cable to connect the two (both using spacetime logs -f quickstart at the same time). Try to flood the logs with for i in {1..1000}; do spacetime call quickstart insert_one_unit_struct; done, then several attempts at closing/restarting spacetime logs -f quickstart
I haven't checked with Bitcraft yet.
My hunch is that were we use:
if format == Format::Json {
let mut stdout = tokio::io::stdout();
while let Some(chunk) = res.chunk().await? {
stdout.write_all(&chunk).await?;
}
return Ok(());
}
It should be stdout.flush().await.unwrap(); before the Ok(()) (that is what the docs of stdout show), but without repro, it is just a guess.
